[[355893]]

前言

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

可以得出：

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

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

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

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

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

Redis Pipeline交互模型

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

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

基本使用

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

使用起來還是很簡(jiǎn)單的

Pipeline的本質(zhì)

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

上圖就是一個(gè)完整的請(qǐng)求交互流程圖：

• 客戶端調(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從接收緩沖中取出消息進(jìn)行處理
• 服務(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 操作是要等到對(duì)方收到消息才會(huì)返回，但實(shí)際上不是這樣的。

• 寫操作 IO 操作的真正耗時(shí)

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

• 讀操作 IO 操作的真正耗時(shí)

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

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

對(duì)于 value = redis.get(key)這樣一個(gè)簡(jiǎn)單的請(qǐng)求來說，write 操作幾乎沒有耗時(shí)，直接 寫到發(fā)送緩沖就返回，而 read 就會(huì)比較耗時(shí)了，因?yàn)樗却⒔?jīng)過網(wǎng)絡(luò)路由到目標(biāo)機(jī)器 處理后的響應(yīng)消息,再回送到當(dāng)前的內(nèi)核讀緩沖才可以返回。

• 管道的真正耗時(shí)

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

優(yōu)缺點(diǎn)

Pipeline的優(yōu)點(diǎn)：

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

Pipeline的缺點(diǎn)：

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

適用場(chǎng)景

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

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

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

使用建議

Pipeline雖然好用，但是每次Pipeline組裝的命令個(gè)數(shù)不能沒有節(jié)制，否則一次組裝Pipeline數(shù)據(jù)量過大，一方面會(huì)增加客戶端的等待時(shí)間，另一方面會(huì)造成一定的網(wǎng)絡(luò)阻塞，可以將一次包含大量命令的Pipeline拆分成多次較小的Pipeline來完成

Pipeline壓力測(cè)試

Redis 自帶了一個(gè)壓力測(cè)試工具 redis-benchmark，使用這個(gè)工具就可以進(jìn)行管道測(cè)試。

小貼士：redis-benchmark官方文檔：https://redis.io/topics/benchmarks

首先我們對(duì)一個(gè)普通的 set 指令進(jìn)行壓測(cè)，QPS 大約 5w/s。

> redis-benchmark -t set -q 
SET: 51975.05 requests per second 

我們加入管道選項(xiàng)-P 參數(shù)，它表示單個(gè)管道內(nèi)并行的請(qǐng)求數(shù)量，看下面 P=2，QPS 達(dá)到 了 9w/s。

> redis-benchmark -t set -P 2 -q 
SET: 91240.88 requests per second 

再看看 P=3，QPS 達(dá)到了 10w/s。

SET: 102354.15 requests per second 

其他問題

為什么pipeline只能作用在一個(gè)Redis節(jié)點(diǎn)上，即集群模式下不能使用pipeline?

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

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

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

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

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

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

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

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

對(duì)比如下：

mset，mget操作在Redis隊(duì)列中是一個(gè)原子操作，pipeline不是原子操作

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

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

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

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

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

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

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

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

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

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

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

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