快捷導(dǎo)航

關(guān)于在Redis中使用Pipelining加速查詢的問題

更新時(shí)間：2022年05月19日 11:00:50 作者：birjemin

這篇文章主要介紹了在Redis中使用Pipelining加速查詢,Redis是一個(gè)client-server模式的TCP服務(wù)，也被稱為Request/Response協(xié)議的實(shí)現(xiàn)，本文通過一個(gè)例子給大家詳細(xì)介紹，感興趣的朋友一起看看吧

Request/Response protocols and RTT

Redis是一個(gè)client-server模式的TCP服務(wù)，也被稱為Request/Response協(xié)議的實(shí)現(xiàn)。

這意味著通常一個(gè)請求的完成是遵循下面兩個(gè)步驟：

Client發(fā)送一個(gè)操作命令給Server，從TCP的套接字Socket中讀取Server的響應(yīng)值，通常來說這是一種阻塞的方式
Server執(zhí)行操作命令，然后將響應(yīng)值返回給Client

舉個(gè)例子

Client: INCR X
Server: 1
Client: INCR X
Server: 2
Client: INCR X
Server: 3
Client: INCR X
Server: 4

Clients和Servers是通過網(wǎng)絡(luò)進(jìn)行連接。這就意味著網(wǎng)絡(luò)連接可能會(huì)很快（比如回環(huán)網(wǎng)絡(luò)，即本機(jī)網(wǎng)絡(luò)），也可能很慢（比如兩個(gè)主機(jī)之間存在多跳網(wǎng)絡(luò)）。不管網(wǎng)絡(luò)怎么樣，一個(gè)數(shù)據(jù)包從Client到Server，然后相應(yīng)值又從Server返回Client都需要一定的時(shí)間。

這個(gè)時(shí)間被稱為RTT(Round Trip Time)。當(dāng)一個(gè)Client需要執(zhí)行多個(gè)連續(xù)請求（比如添加許多個(gè)元素到一個(gè)list中，或者清掉Redis中許多個(gè)鍵值對(duì)），那么RTT是怎樣影響到性能的呢？這個(gè)也是很方便去計(jì)算的。比如如果RTT的時(shí)間為250ms（假設(shè)互聯(lián)網(wǎng)連接速度非常慢），即使Server可以每秒處理100k個(gè)請求，那么最多也只能接受每秒4個(gè)請求。

如果是回環(huán)網(wǎng)絡(luò)，RTT將會(huì)特別的短（比如作者的127.0.0.1，RTT的響應(yīng)時(shí)間為44ms），但是對(duì)于執(zhí)行連續(xù)多次寫操作時(shí)，也是一筆不小的消耗。

其實(shí)我們有其他辦法來降低這種場景的消耗，開心不？驚喜不？

Redis Pipelining

在一個(gè)Request/Response方式的服務(wù)中有一個(gè)特性：即使Client沒有收到之前的響應(yīng)值，也可以繼續(xù)發(fā)送新的請求。這種特性意味著我們可以不需要等待Server的響應(yīng)，可以率先發(fā)送許多操作命令給Server，然后在一次性讀取Server的所有響應(yīng)值。

這種方式被稱為Pipelining技術(shù)，該技術(shù)近幾十年來被廣泛的使用。比如多POP3協(xié)議的實(shí)現(xiàn)就支持這個(gè)特性，大大的提升了從server端下載新的郵件的速度。

Redis在很早的時(shí)候就支持該項(xiàng)技術(shù)，所以不管你運(yùn)行的是什么版本，你都可以使用pipelining技術(shù)，比如這里有一個(gè)使用 netcat 工具的：

$ (printf "PING\r\nPING\r\nPING\r\n"; sleep 1) | nc localhost 6379
+PONG
+PONG
+PONG

現(xiàn)在我們不需要為每一次請求付出RTT的消耗了，而是一次性發(fā)送三個(gè)操作命令。為了便于直觀的理解，還是拿之前的說明，使用pipelining技術(shù)該的實(shí)現(xiàn)順序如下：

Client: INCR X
Client: INCR X
Client: INCR X
Client: INCR X
Server: 1
Server: 2
Server: 3
Server: 4

劃重點(diǎn)（敲黑板）：當(dāng)client使用pipelining發(fā)送操作命令時(shí)，server端將強(qiáng)制使用內(nèi)存來排列響應(yīng)結(jié)果。所以在使用pipelining發(fā)送大量的操作命令的時(shí)候，最好確定一個(gè)合理的命令條數(shù)，一批一批的發(fā)送給Server端，比如發(fā)送10k個(gè)操作命令，讀取響應(yīng)結(jié)果，再發(fā)送10k個(gè)操作命令，以此類推…雖然說耗時(shí)近乎相同，但是額外的內(nèi)存消耗將是這10k操作命令的排列響應(yīng)結(jié)果所需的最大值。（為防止內(nèi)存耗盡，選擇一個(gè)合理的值）

It’s not just a matter of RTT

Pipelining不是減少因?yàn)?RTT 造成消耗的唯一方式，但是它確實(shí)幫助你極大的提升每秒的執(zhí)行命令數(shù)量。事實(shí)的真相是：從訪問相應(yīng)的數(shù)據(jù)結(jié)構(gòu)并且生成答復(fù)結(jié)果的角度來看，不使用pipelining確實(shí)代價(jià)很低；但是從套接字socket I/O的角度來看，恰恰相反。因?yàn)檫@涉及到了read()和write()調(diào)用，需要從用戶態(tài)切換到內(nèi)核態(tài)。這種上下文切換會(huì)特別損耗時(shí)間的。

一旦使用了pipelining技術(shù)，很多操作命令將會(huì)從同一個(gè)read()調(diào)用中執(zhí)行讀操作，大量的答復(fù)結(jié)果將會(huì)被分發(fā)到同一個(gè)write()調(diào)用中執(zhí)行寫操作。基于此，隨著管道的長度增加，每秒執(zhí)行的查詢數(shù)量最開始幾乎呈直線型增加，直到不使用pipelining技術(shù)的基準(zhǔn)的10倍，如下圖：

Some real world code example

不翻譯，基本上就是說使用了pipelining提升了5倍性能。

Pipelining VS Scripting

Redis Scripting(2.6+版本可用)，通過使用在Server端完成大量工作的腳本Scripting，可以更加高效的解決大量pipelining用例。使用腳本Scripting的最大好處就是在讀和寫的時(shí)候消耗更少的性能，使得像讀、寫、計(jì)算這樣的操作更加快速。（當(dāng)client需要寫操作之前獲取讀操作的響應(yīng)結(jié)果時(shí)，pepelining就顯得相形見拙。）有時(shí)候，應(yīng)用可能需要在使用pipelining時(shí)，發(fā)送 EVAL 或者 EVALSHA 命令，這是可行的，并且Redis明確支持這么這種SCRIPT LOAD命令。（它保證可可以調(diào)用 EVALSHA 而不會(huì)有失敗的風(fēng)險(xiǎn)）。

Appendix: Why are busy loops slow even on the loopback interface?

讀完全文，你可能還會(huì)感到疑問：為什么如下的Redis測試基準(zhǔn) benchmark 會(huì)執(zhí)行這么慢，甚至在Client和Server在一個(gè)物理機(jī)上也是如此：

FOR-ONE-SECOND:
    Redis.SET("foo","bar")
END

畢竟Redis進(jìn)程和測試基準(zhǔn)benchmark在相同的機(jī)器上運(yùn)行，并且這是沒有任何實(shí)際的延遲和真實(shí)的網(wǎng)絡(luò)參與，不就是消息通過內(nèi)存從一個(gè)地方拷貝到另一個(gè)地方么？原因是進(jìn)程在操作系統(tǒng)中并不是一直運(yùn)行。真實(shí)的情景是系統(tǒng)內(nèi)核調(diào)度，調(diào)度到進(jìn)程運(yùn)行，它才會(huì)運(yùn)行。比如測試基準(zhǔn)benchmark被允許運(yùn)行，從Redis Server中讀取響應(yīng)內(nèi)容（與最后一次執(zhí)行的命令相關(guān)），并且寫了一個(gè)新的命令。這時(shí)命令將在回環(huán)網(wǎng)絡(luò)的套接字中，但是為了被Redis Server讀取，系統(tǒng)內(nèi)核需要調(diào)度Redis Server進(jìn)程（當(dāng)前正在系統(tǒng)中掛起），周而復(fù)始。所以由于系統(tǒng)內(nèi)核調(diào)度的機(jī)制，就算是在回環(huán)網(wǎng)絡(luò)中，仍然會(huì)涉及到網(wǎng)絡(luò)延遲。簡言之，在網(wǎng)絡(luò)服務(wù)器中衡量性能時(shí)，使用回環(huán)網(wǎng)絡(luò)測試并不是一個(gè)明智的方式。應(yīng)該避免使用此種方式來測試基準(zhǔn)。