1. RTT
Redis 是一種基于客戶端-服務端模型以及請求/響應協議的TCP服務。這意味著通常情況下 Redis 客戶端執行一條命令分為如下四個過程：
- 發送命令
- 命令排隊
- 命令執行
- 返回結果
客戶端向服務端發送一個查詢請求，并監聽Socket返回，通常是以阻塞模式，等待服務端響應。服務端處理命令，并將結果返回給客戶端。客戶端和服務端通過網絡進行連接。這個連接可以很快，也可能很慢。無論網絡如何延遲，數據包總是能從客戶端到達服務端，服務端返回數據給客戶端。
這個時間被稱為 RTT (Round Trip Time)，例如上面過程的發送命令和返回結果兩個過程。當客戶端需要連續執行多次請求時很容易看到這是如何影響性能的（例如，添加多個元素到同一個列表中）。例如，如果 RTT 時間是250毫秒（網絡連接很慢的情況下），即使服務端每秒能處理100k的請求量，那我們每秒最多也只能處理4個請求。如果使用的是本地環回接口，RTT 就短得多，但如如果需要連續執行多次寫入，這也是一筆很大的開銷。
下面我們看一下執行 N 次命令的模型:
2. Pipeline
我們可以使用 Pipeline 改善這種情況。Pipeline 并不是一種新的技術或機制，很多技術上都使用過。RTT 在不同網絡環境下會不同，例如同機房和同機房會比較快，跨機房跨地區會比較慢。Redis 很早就支持 Pipeline 技術，因此無論你運行的是什么版本，你都可以使用 Pipeline 操作 Redis。
Pipeline 能將一組 Redis 命令進行組裝，通過一次 RTT 傳輸給 Redis，再將這組 Redis 命令按照順序執行并將結果返回給客戶端。上圖沒有使用 Pipeline 執行了 N 條命令，整個過程需要 N 次 RTT。下圖為使用 Pipeline 執行 N 條命令，整個過程僅需要 1 次 RTT：
Redis 提供了批量操作命令(例如 mget，mset等)，有效的節約了RTT。但大部分命令是不支持批量操作的。
3. Java Pipeline
Jedis 也提供了對 Pipeline 特性的支持。我們可以借助 Pipeline 來模擬批量刪除，雖然不會像 mget 和 mset 那樣是一個原子命令，但是在絕大數情況下可以使用：
|
1
2
3
4
5
6
7
8
9
10
11
|
public void mdel(List<String> keys){ Jedis jedis = new Jedis("127.0.0.1"); // 創建Pipeline對象 Pipeline pipeline = jedis.pipelined(); for (String key : keys){ // 組裝命令 pipeline.del(key); } // 執行命令 pipeline.sync();} |
4. 性能測試
下表給出了不同網絡環境下非 Pipeline 和 Pipeline 執行 10000 次 set 操作的效果：
| 網絡 | 延遲 | 非Pipeline | Pipeline |
|---|---|---|---|
| 本機 | 0.17ms | 573ms | 134ms |
| 內網服務器 | 0.41ms | 1610ms | 240ms |
| 異地機房 | 7ms | 78499ms | 1104ms |
因測試環境不同可能會得到不同的測試數據，本測試 Pipeline 每次攜帶 100 條命令。
我們可以從上表中得出如下結論:
- Pipeline 執行速度一般比逐條執行要快。
- 客戶端和服務端的網絡延時越大，Pipeline 的效果越明顯。
5. 批量命令與Pipeline對比
下面我們看一下批量命令與 Pipeline 的區別:
- 原生批量命令是原子的，Pipeline 是非原子的。
- 原生批量命令是一個命令對應多個 key，Pipeline 支持多個命令。
- 原生批量命令是 Redis 服務端支持實現的，而 Pipeline 需要服務端和客戶端的共同實現。
6. 注意點
使用 Pipeline 發送命令時，每次 Pipeline 組裝的命令個數不能沒有節制，否則一次組裝的命令數據量過大，一方面會增加客戶端的等待時間，另一方面會造成一定的網絡阻塞，可以將一次包含大量命令的 Pipeline 拆分成多個較小的 Pipeline 來完成。
好了，以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對服務器之家的支持。
原文鏈接：https://mp.weixin.qq.com/s?__biz=MzI0OTYwNTQ4Ng==&mid=2247483970&idx=1&sn=8878f012c1dea49d13267100b7a92ccf
