Redis本身是一個(gè)cs模式的tcp server, client可以通過一個(gè)socket連續(xù)發(fā)起多個(gè)請(qǐng)求命令。 每個(gè)請(qǐng)求命令發(fā)出后client通常會(huì)阻塞并等待redis服務(wù)端處理，redis服務(wù)端處理完后將結(jié)果返回給client。

       redis的pipeline(管道)功能在命令行中沒有，但redis是支持pipeline的，而且在各個(gè)語言版的client中都有相應(yīng)的實(shí)現(xiàn)。 由于網(wǎng)絡(luò)開銷延遲，即算redis server端有很強(qiáng)的處理能力，也由于收到的client消息少，而造成吞吐量小。當(dāng)client 使用pipelining 發(fā)送命令時(shí)，redis server必須部分請(qǐng)求放到隊(duì)列中（使用內(nèi)存）執(zhí)行完畢后一次性發(fā)送結(jié)果；如果發(fā)送的命名很多的話，建議對(duì)返回的結(jié)果加標(biāo)簽，當(dāng)然這也會(huì)增加使用的內(nèi)存；

       Pipeline在某些場(chǎng)景下非常有用，比如有多個(gè)command需要被“及時(shí)的”提交，而且他們對(duì)相應(yīng)結(jié)果沒有互相依賴，而且對(duì)結(jié)果響應(yīng)也無需立即獲得，那么pipeline就可以充當(dāng)這種“批處理”的工具；而且在一定程度上，可以較大的提升性能,性能提升的原因主要是TCP鏈接中較少了“交互往返”的時(shí)間。不過在編碼時(shí)請(qǐng)注意，pipeline期間將“獨(dú)占”鏈接，此期間將不能進(jìn)行非“管道”類型的其他操作，直到pipeline關(guān)閉；如果你的pipeline的指令集很龐大，為了不干擾鏈接中的其他操作，你可以為pipeline操作新建Client鏈接，讓pipeline和其他正常操作分離在2個(gè)client中。不過pipeline事實(shí)上所能容忍的操作個(gè)數(shù)，和socket-output緩沖區(qū)大小/返回結(jié)果的數(shù)據(jù)尺寸都有很大的關(guān)系；同時(shí)也意味著每個(gè)redis-server同時(shí)所能支撐的pipeline鏈接的個(gè)數(shù)，也是有限的，這將受限于server的物理內(nèi)存或網(wǎng)絡(luò)接口的緩沖能力。

下面給大家普及redis為什么要提供pipeline功能。

通常我們用redis做接口緩存后，查詢接口的性能就能提升到ms級(jí)別；
但是redis是純內(nèi)存操作啊，總不至于要到ms吧，根據(jù)官方的 benchmark 單實(shí)例也是能抗 7w+ qps 也就是說單個(gè)redis 操作在redis-server上耗時(shí)大概是 0.014ms，那時(shí)間是消耗到哪里去了？

redis是 client-server 模型，client客戶端將 command 通過tcp網(wǎng)絡(luò)連接發(fā)送到 server服務(wù)端，服務(wù)端執(zhí)行完 command 后將響應(yīng)再通過 tcp 連接發(fā)送給client；

對(duì)于應(yīng)用服務(wù)來說，我們所關(guān)注的性能其實(shí)是客戶端時(shí)間，即前面的整個(gè)執(zhí)行過程，雖然 redis-server 命令執(zhí)行的非?？?，但每次命令執(zhí)行都需要在網(wǎng)絡(luò)上走一遭，按照我們公司redis客戶端中間件統(tǒng)計(jì)的rt，一次命令的執(zhí)行平均是1ms 左右，那么網(wǎng)絡(luò)耗時(shí)占比： 1-0.014 / 1 = 0.98(98%!!! ) 可見，大部分時(shí)間都耗在網(wǎng)絡(luò)io上

所以，減少網(wǎng)絡(luò)io次數(shù)就能大大提供 redis-client 所感知的耗時(shí)，提升應(yīng)用服務(wù)性能，redis提供的 pipeline 功能，讓我們可以提交一個(gè)命令后，不用等這個(gè)返回結(jié)果就可以繼續(xù)執(zhí)行下一個(gè)命令，也就是說，可以執(zhí)行多個(gè)命令后，一次性獲取所有結(jié)果； 這樣就大大減少了在網(wǎng)絡(luò)上的消耗

比如

Client: INCR X
Client: INCR X
Client: INCR X
Client: INCR X

Server: 1
Server: 2
Server: 3
Server: 4

除此之外，減少了網(wǎng)絡(luò)讀寫次數(shù)的同時(shí)，也減少了 redis-server 內(nèi)核態(tài)和用戶態(tài)的上下文切換，進(jìn)一步提高了性能

性能提升了多少？

redis官方聲稱pipeline可帶來10倍的性能提升

測(cè)試機(jī)Intel(R) Xeon(R) CPU E5520 @ 2.27GHz， 用pipeline比沒用pipeline性能提升了將近7倍

// 用pipeline
$ ./redis-benchmark -r 1000000 -n 2000000 -t get,set,lpush,lpop -P 16 -q
SET: 552028.75 requests per second
GET: 707463.75 requests per second
LPUSH: 767459.75 requests per second
LPOP: 770119.38 requests per second

// 沒用pipeline
SET: 122556.53 requests per second
GET: 123601.76 requests per second
LPUSH: 136752.14 requests per second
LPOP: 132424.03 requests per second

注意，使用pipeline的時(shí)候，多個(gè)命令的響應(yīng)是緩存在server端的，所以在 pipeline 里一批命令的數(shù)量不要過多，以免服務(wù)端內(nèi)存壓力過大

其實(shí)，減少網(wǎng)絡(luò)io次數(shù)的處理技巧還是比較常見的，如

• CSS Sprites，將很多小圖標(biāo)合并成一張圖片
• jdbc batch api批量提交sql

參考：

https://redis.io/topics/pipelining

https://redis.io/topics/benchmarks

以上就是redis為什么要提供pipeline功能的詳細(xì)內(nèi)容，更多關(guān)于redis pipeline的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論