# 前言 本篇來介紹一下redis pipeline，主要是由於最近一次在幫開發同學review代碼的時候，發現對redis有個迴圈操作可以優化。場景大概是這樣的，根據某個uid要從redis查詢一批數據，每次大概1000個key左右，如果查得到就返回，否則查db，然後寫回緩存。由於每次要查的key ...
前言
本篇來介紹一下redis pipeline，主要是由於最近一次在幫開發同學review代碼的時候，發現對redis有個迴圈操作可以優化。場景大概是這樣的，根據某個uid要從redis查詢一批數據，每次大概1000個key左右，如果查得到就返回，否則查db，然後寫回緩存。由於每次要查的key比較多，雖然redis單次查詢很快，但如果key很多，每次查詢redis都需要讀寫socket，與client間的網路數據傳輸，都需要消耗時間，累加起來也會變得非常慢。開發同學決定使用批量的方式，例如每次操作100個key，使用RedisTemplate批量查詢代碼如下：
redisTemplate.opsForValue().multiGet(keys);
如果查詢到的是null，則表示緩存不存在或過期，則查詢資料庫，再批量寫回redis，偽代碼如下：
for (Long id : list) {
operations.opsForValue().set("key", id, 30, TimeUnit.MINUTES);
}
他並沒有使用批量的方式，如果有100個，這裡就需要執行100次set命令，經過瞭解後原因是批量寫入並不能設置過期時間，我們看它的api確實只能設置key-value，但沒有過期時間也是不行的。
void multiSet(Map<? extends K, ? extends V> map);
單個迴圈設置肯定不行，除了自己執行方法會比較慢，影響用戶體驗，可能導致介面超時外，由於redis是單線程執行命令的，還會影響其它命令的執行，所以必須優化。
優化的方式就是本篇要介紹的：pipeline。
pipeline
pipeline是管道的意思，它最主要的作用就是降低RRT(client-server數據傳輸往返時間)。在請求-響應過程，除了傳遞我們的數據，還需要協議信息，例如http協議的請求頭，響應頭，這些信息也會增加傳輸時間。舉個例子，假設一次RRT是10ms，那麼執行10條命令，就需要100ms，如果我們將其打包到一起執行，RRT就還是10ms（雖然傳輸的數據變多了，但協議本身的信息沒有變多，基本可以忽略不計），傳輸效率提升了10倍。除此之外，redis server每次處理命令都需要對Socket進行IO操作，這涉及到用戶態、內核態的切換，如果批量進行處理，對性能的提升也很有幫助。
pineline將一批命令打包一起執行，但不保證他們的原子性，不像事務一樣可以保證一起成功或失敗，可能前面的命令執行成功了，後面的執行失敗。
這和我們平時操作資料庫的思想是一樣的，單個查詢轉換為批量查詢，單個插入轉換為批量插入，同樣需要註意是，批量雖好，但不能一次過多，否則處理起來比較久，反而得不償失。
更多的知識可參考官方文檔：https://redis.io/docs/manual/pipelining/
我們使用springboot 2.x版本，使用spring-boot-starter-data-redis，它給我們預設集成的redis client是lettuce。在使用一個不熟悉或比較新的東西的時候，本人有一個習慣，會先google一下，例如：“RedisTemplate pipeline 註意事項”，“RedisTemplate pipeline 坑”，看看有沒有前人踩過坑，借鑒一下。這次也一樣，google之後果然發現有點坑，例如這篇提到的Spring Data Redis與Lettuce使用pipeline時，實際命令並不是一起執行的，有時是單條執行，有時是合併幾條執行。
我們自己寫下測試代碼如下：
redisTemplate.executePipelined(new SessionCallback<Object>() {
@Override
public Object execute(RedisOperations operations) throws DataAccessException {
for (int i = 0; i < 100; i++) {
operations.opsForValue().set("testPipeline2" + i, i, 1, TimeUnit.MINUTES);
}
return null;
}
});
在set位置打個斷點，然後到redis server使用monitor命令觀察，看命令到底是不是一條一條給過來的。monitor命令會將server執行的命令都列印出來，生產環境慎用。
按照上面的分析，正常情況下這些命令應該是一起發送到server端一起執行的，不會斷斷續續，但實際我們觀察確實不是一起給過來，斷斷續續的，如下：
我們把lettuce替換成jedis看看。
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-redis</artifactId>
<exclusions>
<exclusion>
<groupId>io.lettuce</groupId>
<artifactId>lettuce-core</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>redis.clients</groupId>
<artifactId>jedis</artifactId>
</dependency>
還是執行上面的代碼，打斷點，使用jedis可以觀察到，每次迴圈monitor都不會觀察到有命令執行，直到最後才一批給過來。
但我們不想直接替換lettuce為jedis，一個是它是spring boot預設集成的，擁有更好的性能，二是替換後不知道其它功能有沒有影響，那怎麼辦呢？
我們項目還使用redission分散式鎖，其實redission也是一個redis client，理論上它應該實現所有client的功能，pipeline自然也有實現。
我們使用redission如下：
RBatch batch = redissonClient.createBatch();
for (int i = 0; i < 100; i++) {
batch.getBucket("testBatch" + i).setAsync(i, 1, TimeUnit.MINUTES);
}
batch.execute();
這次我們把斷點打在execute位置，看看是不是execute時才一起提交到server執行，答案顯然是的。
接下來我們簡單測試一下性能差距，分別是單個請求，使用lettuce，使用jedis，使用redission，執行10000次，耗時如下：
單個請求：73029ms
lettuce: 712ms
jedis: 413ms
redission: 341ms
lettuce出乎意料執行還是很快，就想上面提到的，它有時還是會部分打包一起執行，但終究不是一次執行，有興趣的可以深入瞭解一下。
更多分享，歡迎關註我的github：https://github.com/jmilktea/jtea
