Redis如何解決頻繁的命令往返造成的性能瓶頸
前言
先來看看Redis客戶端和服務端的交互模型
可以得出：
1.Redis是基于一個Request，一個Response的同步請求服務
2.客戶端將數據包發送至服務器，然后服務器再將響應數據發送回客戶端，這都需要花費一定時間的。這段時間被稱為往返時間RTT(Round Trip Time)。
當一個客戶端需要連續執行很多請求時，就很容易看出往返時間是影響系統性能的
例如：如果往返時間RTT是250毫秒，即使Redis服務器每秒鐘能處理1000個請求，我們也只能每秒鐘最多處理四個請求。
Redis提供了一種Pipeline(管道)方法可以改善上述用例的性能，下面看看。
Redis Pipeline交互模型
可以看到，客戶端首先將執行的命令寫入到緩沖區(內存)中，最后再一次性發送 Redis。
pipeline通過將一批命令進行打包，然后發送給服務器，服務器執行完按順序打包返回，這樣就減少了頻繁交互往返的時間，提升了性能
基本使用
- Pipeline pipeline =jedis.pipelined();
- // 循環添加 1000個元素
- for(int i = 0; i < 1000; i++){
- pipeline.rpush("rediskey", i + "");
- }
- //執行
- pipeline.sync()
使用起來還是很簡單的
Pipeline的本質
我們深入分析一個請求交互的流程，真實的情況是它很復雜的
上圖就是一個完整的請求交互流程圖：
- 客戶端調用write將消息寫到操作系統內核為套接字分配的發送緩沖中send buffer
- 系統內核將緩沖區的內容發送到網卡，網卡硬件將數據通過路由送到服務器的網卡
- 服務器網卡將數據放到內核為套接字分配的接收緩沖中recive buffer
- 服務器調用read從接收緩沖中取出消息進行處理
- 服務器調用write將響應內容發送到send bffer中
- 服務器內核將緩沖區的內容通過路由發送到客戶端的網卡中
- 客戶端內核將網卡中的數據放到接收緩沖中recive buffer
- 客戶端調用read從緩沖中讀取數據
總結
我們開始以為 write 操作是要等到對方收到消息才會返回，但實際上不是這樣的。
- 寫操作 IO 操作的真正耗時
write 操作只負責將數據寫到本地操作系統內核的發送緩沖然后就返回了。剩下的事交給操作系統內核異步將數據送到目標機器。但是如果發送緩沖滿了，那么就需要等待緩沖空出空閑空間來，這個就是寫操作 IO 操作的真正耗時。
- 讀操作 IO 操作的真正耗時
我們開始以為 read 操作是從目標機器拉取數據，但實際上不是這樣的。read 操作只負 責將數據從本地操作系統內核的接收緩沖中取出來就了事了。但是如果緩沖是空的，那么就 需要等待數據到來，這個就是讀操作 IO 操作的真正耗時。
- value = redis.get(key)操作耗時
對于 value = redis.get(key)這樣一個簡單的請求來說，write 操作幾乎沒有耗時，直接 寫到發送緩沖就返回，而 read 就會比較耗時了，因為它要等待消息經過網絡路由到目標機器 處理后的響應消息,再回送到當前的內核讀緩沖才可以返回。
- 管道的真正耗時
對于管道來說，連續的 write 操作根本就沒有耗時，之后第一個 read 操作會等待一個 網絡的來回開銷，然后所有的響應消息就都已經回送到內核的讀緩沖了，后續的 read 操作 直接就可以從緩沖拿到結果，瞬間就返回了。
優缺點
Pipeline的優點：
pipeline 通過打包命令，一次性執行，可以節省連接->發送命令->返回結果這個過程所產生的往返時間，減少的I/O的調用(用戶態到內核態之間的切換)次數。
Pipeline的缺點：
- pipeline 每批打包的命令不能過多，因為 pipeline 方式打包命令再發送，那么 redis 必須在處理完所有命令前先緩存起所有命令的處理結果。這樣就有一個內存的消耗。
- pipeline不保證原子性，執行命令過程中，如果一個命令出現異常，也會繼續執行其他命令，所以如果要求原子性的，不推薦使用 pipeline
- pipeline每次只能作用在一個Redis節點上(下面會解釋原因)
適用場景
有些系統可能對可靠性要求很高，每次操作都需要立馬知道這次操作是否成功，是否數據已經寫進redis了，那這種場景就不適合。
有的系統，可能是批量的將數據寫入redis，允許一定比例的寫入失敗，那么這種場景就可以使用了，比如10000條一下進入redis，可能失敗了2條無所謂，后期有補償機制就行了
比如短信群發這種場景，如果一下群發10000條，按照第一種模式去實現，那這個請求過來，要很久才能給客戶端響應，這個延遲就太長了，如果客戶端請求設置了超時時間5秒，那肯定就拋出異常了，而且本身群發短信要求實時性也沒那么高，這時候用pipeline最好了。
使用建議
Pipeline雖然好用，但是每次Pipeline組裝的命令個數不能沒有節制，否則一次組裝Pipeline數據量過大，一方面會增加客戶端的等待時間，另一方面會造成一定的網絡阻塞，可以將一次包含大量命令的Pipeline拆分成多次較小的Pipeline來完成
Pipeline壓力測試
Redis 自帶了一個壓力測試工具 redis-benchmark，使用這個工具就可以進行管道測試。
小貼士：redis-benchmark官方文檔：https://redis.io/topics/benchmarks
首先我們對一個普通的 set 指令進行壓測，QPS 大約 5w/s。
- > redis-benchmark -t set -q
- SET: 51975.05 requests per second
我們加入管道選項-P 參數，它表示單個管道內并行的請求數量，看下面 P=2，QPS 達到 了 9w/s。
- > redis-benchmark -t set -P 2 -q
- SET: 91240.88 requests per second
再看看 P=3，QPS 達到了 10w/s。
- SET: 102354.15 requests per second
其他問題
為什么pipeline只能作用在一個Redis節點上，即集群模式下不能使用pipeline?
我們知道，Redis 集群的鍵空間被分割為 16384 個槽(slot)，每個主節點都負責處理 16384 個哈希槽的其中一部分。
具體的redis命令，會根據key計算出一個槽位(slot),然后根據槽位去特定的節點redis上執行操作。如下所示：
- master1（slave1）： 0~5460
- master2（slave2）：5461~10922
- master3（slave3）：10923~16383
集群有三個master節點組成，其中master1分配了 0~5460的槽位，master2分配了 5461~10922的槽位，master3分配了 10923~16383的槽位。
一次pipeline會批量執行多個命令，那么每個命令都需要根據key運算一個槽位(CRC16.getSlot(key))，然后根據槽位去特定的節點上執行命令，也就是說一次pipeline操作會使用多個節點的redis連接，而目前是無法支持的
小貼士：不了解Redis集群知識的，可以參考：https://redis.io/topics/cluster-tutorial
pipeline和mget、mset等批量操作區別?
mget，mset也是類似 pipeline，將多個命令一次執行，一次發送出去，節省網絡時間。
對比如下：
mset，mget操作在Redis隊列中是一個原子操作，pipeline不是原子操作
mset，mget操作一個命令對應多個鍵值對，而pipeline是多條命令
mset，mget是服務端實現，而pipeline是服務端和客戶端共同完成
pipeline和事務區別?
pipeline關注的是RTT時間，而事務關注的是一致性
- pipeline是一次請求，服務端順序執行，一次返回，事務多次請求(MULTI命令+其他n個命令+EXEC命令，所以至少是2次請求)，服務端順序執行，一次返回。
- 集群模式下，使用pipeline時，slot槽必須是對的，不然服務端會返回redirecred to slot xxx的錯誤;同時不建議使用事務，因為假設一個事務中的命令即在Master A上執行，也在Master B執行，A成功了，B因為某種原因失敗了，這樣數據就不一致了，這個有點類似于分布式事務，無法保證絕對一致性。
Pipeline對命令數量是否有限制?
沒有限制，但是打包的命令不能過多，對內存的消耗就越大。
Pipeline打包執行多少命令合適?
查詢 Redis 官方文檔，根據官方文檔的解釋，推薦是以 10k 每批 (注意：這個是一個參考值，請根據自身實際業務情況調整)。
Pipeline批量執行的時候，是否導致其他應用無法再進行讀寫?
Redis 采用多路I/O復用模型，非阻塞IO，所以Pipeline批量寫入的時候，一定范圍內不影響其他的讀操作。
本文轉載自微信公眾號「月伴飛魚」，可以通過以下二維碼關注。轉載本文請聯系月伴飛魚公眾號。日常加油站
