1. RTT

Redis 是一種基于客戶端-服務端模型以及請求/響應協(xié)議的TCP服務。這意味著通常情況下 Redis 客戶端執(zhí)行一條命令分為如下四個過程：

• 發(fā)送命令
• 命令排隊
• 命令執(zhí)行
• 返回結果

客戶端向服務端發(fā)送一個查詢請求，并監(jiān)聽Socket返回，通常是以阻塞模式，等待服務端響應。服務端處理命令，并將結果返回給客戶端。客戶端和服務端通過網絡進行連接。這個連接可以很快，也可能很慢。無論網絡如何延遲，數(shù)據(jù)包總是能從客戶端到達服務端，服務端返回數(shù)據(jù)給客戶端。

這個時間被稱為 RTT (Round Trip Time)，例如上面過程的發(fā)送命令和返回結果兩個過程。當客戶端需要連續(xù)執(zhí)行多次請求時很容易看到這是如何影響性能的（例如，添加多個元素到同一個列表中）。例如，如果 RTT 時間是250毫秒（網絡連接很慢的情況下），即使服務端每秒能處理100k的請求量，那我們每秒最多也只能處理4個請求。如果使用的是本地環(huán)回接口，RTT 就短得多，但如如果需要連續(xù)執(zhí)行多次寫入，這也是一筆很大的開銷。

下面我們看一下執(zhí)行 N 次命令的模型:

2. Pipeline

我們可以使用 Pipeline 改善這種情況。Pipeline 并不是一種新的技術或機制，很多技術上都使用過。RTT 在不同網絡環(huán)境下會不同，例如同機房和同機房會比較快，跨機房跨地區(qū)會比較慢。Redis 很早就支持 Pipeline 技術，因此無論你運行的是什么版本，你都可以使用 Pipeline 操作 Redis。

Pipeline 能將一組 Redis 命令進行組裝，通過一次 RTT 傳輸給 Redis，再將這組 Redis 命令按照順序執(zhí)行并將結果返回給客戶端。上圖沒有使用 Pipeline 執(zhí)行了 N 條命令，整個過程需要 N 次 RTT。下圖為使用 Pipeline 執(zhí)行 N 條命令，整個過程僅需要 1 次 RTT：

Redis 提供了批量操作命令(例如 mget，mset等)，有效的節(jié)約了RTT。但大部分命令是不支持批量操作的。

3. Java Pipeline

Jedis 也提供了對 Pipeline 特性的支持。我們可以借助 Pipeline 來模擬批量刪除，雖然不會像 mget 和 mset 那樣是一個原子命令，但是在絕大數(shù)情況下可以使用：

public void mdel(ListString> keys){
 Jedis jedis = new Jedis("127.0.0.1");
 // 創(chuàng)建Pipeline對象
 Pipeline pipeline = jedis.pipelined();
 for (String key : keys){
  // 組裝命令
  pipeline.del(key);
 }
 // 執(zhí)行命令
 pipeline.sync();
}

4. 性能測試

下表給出了不同網絡環(huán)境下非 Pipeline 和 Pipeline 執(zhí)行 10000 次 set 操作的效果：