目錄java
Redis是一種基於客戶端-服務端模型(C/S模型)
以及請求/響應協議
的TCP服務。git
這意味着一般狀況下一個請求會遵循如下步驟:github
客戶端向服務端發送一個查詢請求,並監聽Socket返回,一般是以阻塞模式,等待服務端響應。redis
服務端處理命令,並將結果返回給客戶端。spring
這就是普通請求模型。springboot
所謂RTT(Round-Trip Time),就是往返時延,在計算機網絡中它是一個重要的性能指標,表示從發送端發送數據開始,到發送端收到來自接收端的確認(接收端收到數據後便當即發送確認),總共經歷的時延。bash
通常認爲,單向時延 = 傳輸時延t1 + 傳播時延t2 + 排隊時延t3服務器
爲了解決這個問題,Redis支持經過管道,來達到減小RTT的目的。網絡
SpringDataRedis提供了executePipelined
方法對管道進行支持。併發
下面是一個Redis隊列的操做,放到了管道中進行操做。
package net.ijiangtao.tech.framework.spring.ispringboot.redis.pipelining;
import lombok.extern.slf4j.Slf4j;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.dao.DataAccessException;
import org.springframework.data.redis.connection.RedisConnection;
import org.springframework.data.redis.core.ListOperations;
import org.springframework.data.redis.core.RedisCallback;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.test.context.junit4.SpringRunner;
import java.time.Duration;
import java.time.Instant;
/** * Redis Pipelining * * @author ijiangtao * @create 2019-04-13 22:32 **/
@RunWith(SpringRunner.class)
@SpringBootTest
@Slf4j
public class RedisPipeliningTests {
@Autowired
private RedisTemplate<String, String> redisTemplate;
private static final String RLIST = "test_redis_list";
@Test
public void test() {
Instant beginTime2 = Instant.now();
redisTemplate.executePipelined(new RedisCallback<Object>() {
@Override
public Object doInRedis(RedisConnection connection) throws DataAccessException {
for (int i = 0; i < (10 * 10000); i++) {
connection.lPush(RLIST.getBytes(), (i + "").getBytes());
}
for (int i = 0; i < (10 * 10000); i++) {
connection.rPop(RLIST.getBytes());
}
return null;
}
});
log.info(" ***************** pipeling time duration : {}", Duration.between(beginTime2, Instant.now()).getSeconds());
}
}
複製代碼
注意executePipelined
中的doInRedis
方法返回總爲null
。
上面簡單演示了管道的使用方式,那麼管道的性能究竟如何呢?
下面咱們一塊兒來驗證一下。
首先,redis提供了redis-benchmark
工具測試性能,我在本身的電腦上經過cmd打開命令行,不使用管道,進行了一百萬次set和get操做,效果以下:
$ redis-benchmark -n 1000000 -t set,get -q
SET: 42971.94 requests per second
GET: 46737.71 requests per second
複製代碼
平均每秒處理4萬屢次操做請求。
經過-P
命令使用管道,效果以下:
$ redis-benchmark -n 1000000 -t set,get -P 16 –q
SET: 198098.27 requests per second
GET: 351988.72 requests per second
複製代碼
使用管道之後,set和get的速度變成了每秒將近20萬次和35萬次。
而後我在服務器上,測試了使用SpringDataRedis進行rpop
出隊2000次的性能。
分別使用單線程出隊、32個線程併發出隊和單線程管道出隊。下面是測試的結果:
從統計結果來看,出隊2000次,在單線程下大約須要6秒;32個線程併發請求大約須要2秒;而單線程下使用管道只須要70毫秒左右。
當你要進行頻繁的Redis請求的時候,爲了達到最佳性能,下降RTT,你應該使用管道技術。
但若是經過管道發送了太多請求,也會形成Redis的CPU使用率太高。
下面是經過循環向Redis發送出隊指令來監聽隊列的CUP使用狀況:
當管道中累計了大量請求之後,CUP使用率迅速升到了100%,這是很是危險的操做。
對於監聽隊列的場景,一個簡單的作法是當發現隊列返回的內容爲空的時候,就讓線程休眠幾秒鐘,等隊列中累積了必定量數據之後再經過管道去取,這樣就既能享受管道帶來的高性能,又避免了CPU使用率太高的風險。
Thread.currentThread().sleep(10 * 1000);
複製代碼