目錄
Redis 管道技術
Redis是一種基於客戶端-服務端模型(C/S模型)以及請求/響應協議的TCP服務。
這意味著通常情況下一個請求會遵循以下步驟：
-
客戶端向服務端傳送一個查詢請求，並監聽Socket返回，通常是以阻塞模式，等待服務端響應。
-
服務端處理命令，並將結果返回給客戶端。
這就是普通請求模型。
所謂RTT(Round-Trip Time)，就是往返時延，在計算機網路中它是一個重要的效能指標，表示從傳送端傳送資料開始，到傳送端收到來自接收端的確認（接收端收到資料後便立即傳送確認），總共經歷的時延。
一般認為，單向時延 = 傳輸時延t1 + 傳播時延t2 + 排隊時延t3
為了解決這個問題，Redis支援通過管道，來達到減少RTT的目的。
SpringDataRedis 使用管道
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提供了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);
複製程式碼