[[355893]]

前言

先來看看Redis客戶端和服務(wù)端的交互模型

可以得出：

1.Redis是基于一個Request，一個Response的同步請求服務(wù)

2.客戶端將數(shù)據(jù)包發(fā)送至服務(wù)器，然后服務(wù)器再將響應(yīng)數(shù)據(jù)發(fā)送回客戶端，這都需要花費一定時間的。這段時間被稱為往返時間RTT(Round Trip Time)。

當(dāng)一個客戶端需要連續(xù)執(zhí)行很多請求時，就很容易看出往返時間是影響系統(tǒng)性能的

例如：如果往返時間RTT是250毫秒，即使Redis服務(wù)器每秒鐘能處理1000個請求，我們也只能每秒鐘最多處理四個請求。

Redis提供了一種Pipeline(管道)方法可以改善上述用例的性能，下面看看。

Redis Pipeline交互模型

可以看到，客戶端首先將執(zhí)行的命令寫入到緩沖區(qū)(內(nèi)存)中，最后再一次性發(fā)送 Redis。

pipeline通過將一批命令進行打包，然后發(fā)送給服務(wù)器，服務(wù)器執(zhí)行完按順序打包返回，這樣就減少了頻繁交互往返的時間，提升了性能

基本使用

Pipeline pipeline =jedis.pipelined(); 
// 循環(huán)添加 1000個元素 
for(int i = 0; i < 1000; i++){ 
    pipeline.rpush("rediskey", i + ""); 
        } 
//執(zhí)行  
pipeline.sync() 

使用起來還是很簡單的

Pipeline的本質(zhì)

我們深入分析一個請求交互的流程，真實的情況是它很復(fù)雜的

上圖就是一個完整的請求交互流程圖：

• 客戶端調(diào)用write將消息寫到操作系統(tǒng)內(nèi)核為套接字分配的發(fā)送緩沖中send buffer
• 系統(tǒng)內(nèi)核將緩沖區(qū)的內(nèi)容發(fā)送到網(wǎng)卡，網(wǎng)卡硬件將數(shù)據(jù)通過路由送到服務(wù)器的網(wǎng)卡
• 服務(wù)器網(wǎng)卡將數(shù)據(jù)放到內(nèi)核為套接字分配的接收緩沖中recive buffer
• 服務(wù)器調(diào)用read從接收緩沖中取出消息進行處理
• 服務(wù)器調(diào)用write將響應(yīng)內(nèi)容發(fā)送到send bffer中
• 服務(wù)器內(nèi)核將緩沖區(qū)的內(nèi)容通過路由發(fā)送到客戶端的網(wǎng)卡中
• 客戶端內(nèi)核將網(wǎng)卡中的數(shù)據(jù)放到接收緩沖中recive buffer
• 客戶端調(diào)用read從緩沖中讀取數(shù)據(jù)

總結(jié)

我們開始以為 write 操作是要等到對方收到消息才會返回，但實際上不是這樣的。

• 寫操作 IO 操作的真正耗時

write 操作只負(fù)責(zé)將數(shù)據(jù)寫到本地操作系統(tǒng)內(nèi)核的發(fā)送緩沖然后就返回了。剩下的事交給操作系統(tǒng)內(nèi)核異步將數(shù)據(jù)送到目標(biāo)機器。但是如果發(fā)送緩沖滿了，那么就需要等待緩沖空出空閑空間來，這個就是寫操作 IO 操作的真正耗時。

• 讀操作 IO 操作的真正耗時

我們開始以為 read 操作是從目標(biāo)機器拉取數(shù)據(jù)，但實際上不是這樣的。read 操作只負(fù) 責(zé)將數(shù)據(jù)從本地操作系統(tǒng)內(nèi)核的接收緩沖中取出來就了事了。但是如果緩沖是空的，那么就 需要等待數(shù)據(jù)到來，這個就是讀操作 IO 操作的真正耗時。

• value = redis.get(key)操作耗時

對于 value = redis.get(key)這樣一個簡單的請求來說，write 操作幾乎沒有耗時，直接 寫到發(fā)送緩沖就返回，而 read 就會比較耗時了，因為它要等待消息經(jīng)過網(wǎng)絡(luò)路由到目標(biāo)機器 處理后的響應(yīng)消息,再回送到當(dāng)前的內(nèi)核讀緩沖才可以返回。

• 管道的真正耗時

對于管道來說，連續(xù)的 write 操作根本就沒有耗時，之后第一個 read 操作會等待一個 網(wǎng)絡(luò)的來回開銷，然后所有的響應(yīng)消息就都已經(jīng)回送到內(nèi)核的讀緩沖了，后續(xù)的 read 操作 直接就可以從緩沖拿到結(jié)果，瞬間就返回了。

優(yōu)缺點

Pipeline的優(yōu)點：

pipeline 通過打包命令，一次性執(zhí)行，可以節(jié)省連接->發(fā)送命令->返回結(jié)果這個過程所產(chǎn)生的往返時間，減少的I/O的調(diào)用(用戶態(tài)到內(nèi)核態(tài)之間的切換)次數(shù)。

Pipeline的缺點：

• pipeline 每批打包的命令不能過多，因為 pipeline 方式打包命令再發(fā)送，那么 redis 必須在處理完所有命令前先緩存起所有命令的處理結(jié)果。這樣就有一個內(nèi)存的消耗。
• pipeline不保證原子性，執(zhí)行命令過程中，如果一個命令出現(xiàn)異常，也會繼續(xù)執(zhí)行其他命令，所以如果要求原子性的，不推薦使用 pipeline
• pipeline每次只能作用在一個Redis節(jié)點上(下面會解釋原因)

適用場景

有些系統(tǒng)可能對可靠性要求很高，每次操作都需要立馬知道這次操作是否成功，是否數(shù)據(jù)已經(jīng)寫進redis了，那這種場景就不適合。

有的系統(tǒng)，可能是批量的將數(shù)據(jù)寫入redis，允許一定比例的寫入失敗，那么這種場景就可以使用了，比如10000條一下進入redis，可能失敗了2條無所謂，后期有補償機制就行了

比如短信群發(fā)這種場景，如果一下群發(fā)10000條，按照第一種模式去實現(xiàn)，那這個請求過來，要很久才能給客戶端響應(yīng)，這個延遲就太長了，如果客戶端請求設(shè)置了超時時間5秒，那肯定就拋出異常了，而且本身群發(fā)短信要求實時性也沒那么高，這時候用pipeline最好了。

使用建議

Pipeline雖然好用，但是每次Pipeline組裝的命令個數(shù)不能沒有節(jié)制，否則一次組裝Pipeline數(shù)據(jù)量過大，一方面會增加客戶端的等待時間，另一方面會造成一定的網(wǎng)絡(luò)阻塞，可以將一次包含大量命令的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 參數(shù)，它表示單個管道內(nèi)并行的請求數(shù)量，看下面 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節(jié)點上，即集群模式下不能使用pipeline?

我們知道，Redis 集群的鍵空間被分割為 16384 個槽(slot)，每個主節(jié)點都負(fù)責(zé)處理 16384 個哈希槽的其中一部分。

具體的redis命令，會根據(jù)key計算出一個槽位(slot),然后根據(jù)槽位去特定的節(jié)點redis上執(zhí)行操作。如下所示：

master1（slave1）： 0~5460 
master2（slave2）：5461~10922 
master3（slave3）：10923~16383 

集群有三個master節(jié)點組成，其中master1分配了 0~5460的槽位，master2分配了 5461~10922的槽位，master3分配了 10923~16383的槽位。

一次pipeline會批量執(zhí)行多個命令，那么每個命令都需要根據(jù)key運算一個槽位(CRC16.getSlot(key))，然后根據(jù)槽位去特定的節(jié)點上執(zhí)行命令，也就是說一次pipeline操作會使用多個節(jié)點的redis連接，而目前是無法支持的

小貼士：不了解Redis集群知識的，可以參考：https://redis.io/topics/cluster-tutorial

pipeline和mget、mset等批量操作區(qū)別?

mget，mset也是類似 pipeline，將多個命令一次執(zhí)行，一次發(fā)送出去，節(jié)省網(wǎng)絡(luò)時間。

對比如下：

mset，mget操作在Redis隊列中是一個原子操作，pipeline不是原子操作

mset，mget操作一個命令對應(yīng)多個鍵值對，而pipeline是多條命令

mset，mget是服務(wù)端實現(xiàn)，而pipeline是服務(wù)端和客戶端共同完成

pipeline和事務(wù)區(qū)別?

pipeline關(guān)注的是RTT時間，而事務(wù)關(guān)注的是一致性

• pipeline是一次請求，服務(wù)端順序執(zhí)行，一次返回，事務(wù)多次請求(MULTI命令+其他n個命令+EXEC命令，所以至少是2次請求)，服務(wù)端順序執(zhí)行，一次返回。
• 集群模式下，使用pipeline時，slot槽必須是對的，不然服務(wù)端會返回redirecred to slot xxx的錯誤;同時不建議使用事務(wù)，因為假設(shè)一個事務(wù)中的命令即在Master A上執(zhí)行，也在Master B執(zhí)行，A成功了，B因為某種原因失敗了，這樣數(shù)據(jù)就不一致了，這個有點類似于分布式事務(wù)，無法保證絕對一致性。

Pipeline對命令數(shù)量是否有限制?

沒有限制，但是打包的命令不能過多，對內(nèi)存的消耗就越大。

Pipeline打包執(zhí)行多少命令合適?

查詢 Redis 官方文檔，根據(jù)官方文檔的解釋，推薦是以 10k 每批 (注意：這個是一個參考值，請根據(jù)自身實際業(yè)務(wù)情況調(diào)整)。

Pipeline批量執(zhí)行的時候，是否導(dǎo)致其他應(yīng)用無法再進行讀寫?

Redis 采用多路I/O復(fù)用模型，非阻塞IO，所以Pipeline批量寫入的時候，一定范圍內(nèi)不影響其他的讀操作。

本文轉(zhuǎn)載自微信公眾號「月伴飛魚」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系月伴飛魚公眾號。日常加油站