快捷導(dǎo)航

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

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

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

Request/Response protocols and RTT

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

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

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

舉個例子

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

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

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

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

Redis Pipelining

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

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

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

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

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

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

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

It’s not just a matter of RTT

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

一旦使用了pipelining技術(shù)，很多操作命令將會從同一個read()調(diào)用中執(zhí)行讀操作，大量的答復(fù)結(jié)果將會被分發(fā)到同一個write()調(diào)用中執(zhí)行寫操作?；诖耍S著管道的長度增加，每秒執(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的最大好處就是在讀和寫的時候消耗更少的性能，使得像讀、寫、計算這樣的操作更加快速。（當(dāng)client需要寫操作之前獲取讀操作的響應(yīng)結(jié)果時，pepelining就顯得相形見拙。）有時候，應(yīng)用可能需要在使用pipelining時，發(fā)送 EVAL 或者 EVALSHA 命令，這是可行的，并且Redis明確支持這么這種SCRIPT LOAD命令。（它保證可可以調(diào)用 EVALSHA 而不會有失敗的風(fēng)險）。

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

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

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

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