關於在Redis中使用Pipelining加速查詢的問題

2022-05-19 13:01:51

Request/Response protocols and RTT

Redis是一個client-server模式的TCP服務，也被稱為Request/Response協定的實現。

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

Client傳送一個操作命令給Server，從TCP的通訊端Socket中讀取Server的響應值，通常來說這是一種阻塞的方式
Server執行操作命令，然後將響應值返回給Client

舉個例子

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

Clients和Servers是通過網路進行連線。這就意味著網路連線可能會很快（比如迴環網路，即本機網路），也可能很慢（比如兩個主機之間存在多跳網路）。不管網路怎麼樣，一個封包從Client到Server，然後相應值又從Server返回Client都需要一定的時間。

這個時間被稱為RTT(Round Trip Time)。當一個Client需要執行多個連續請求（比如新增許多個元素到一個list中，或者清掉Redis中許多個鍵值對），那麼RTT是怎樣影響到效能的呢？這個也是很方便去計算的。比如如果RTT的時間為250ms（假設網際網路連線速度非常慢），即使Server可以每秒處理100k個請求，那麼最多也只能接受每秒4個請求。

如果是迴環網路，RTT將會特別的短（比如作者的127.0.0.1，RTT的響應時間為44ms），但是對於執行連續多次寫操作時，也是一筆不小的消耗。

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

Redis Pipelining

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

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

Redis在很早的時候就支援該項技術，所以不管你執行的是什麼版本，你都可以使用pipelining技術，比如這裡有一個使用 netcat 工具的：

$ (printf "PINGrnPINGrnPINGrn"; sleep 1) | nc localhost 6379
+PONG
+PONG
+PONG

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

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

劃重點（敲黑板）：當client使用pipelining傳送操作命令時，server端將強制使用記憶體來排列響應結果。所以在使用pipelining傳送大量的操作命令的時候，最好確定一個合理的命令條數，一批一批的傳送給Server端，比如傳送10k個操作命令，讀取響應結果，再傳送10k個操作命令，以此類推…雖然說耗時近乎相同，但是額外的記憶體消耗將是這10k操作命令的排列響應結果所需的最大值。（為防止記憶體耗盡，選擇一個合理的值）

It’s not just a matter of RTT

Pipelining不是減少因為 RTT 造成消耗的唯一方式，但是它確實幫助你極大的提升每秒的執行命令數量。事實的真相是：從存取相應的資料結構並且生成答覆結果的角度來看，不使用pipelining確實代價很低；但是從通訊端socket I/O的角度來看，恰恰相反。因為這涉及到了read()和write()呼叫，需要從使用者態切換到核心態。這種上下文切換會特別損耗時間的。

一旦使用了pipelining技術，很多操作命令將會從同一個read()呼叫中執行讀操作，大量的答覆結果將會被分發到同一個write()呼叫中執行寫操作。基於此，隨著管道的長度增加，每秒執行的查詢數量最開始幾乎呈直線型增加，直到不使用pipelining技術的基準的10倍，如下圖：

Some real world code example

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

Pipelining VS Scripting

Redis Scripting(2.6+版本可用)，通過使用在Server端完成大量工作的指令碼Scripting，可以更加高效的解決大量pipelining用例。使用指令碼Scripting的最大好處就是在讀和寫的時候消耗更少的效能，使得像讀、寫、計算這樣的操作更加快速。（當client需要寫操作之前獲取讀操作的響應結果時，pepelining就顯得相形見拙。）有時候，應用可能需要在使用pipelining時，傳送 EVAL 或者 EVALSHA 命令，這是可行的，並且Redis明確支援這麼這種SCRIPT LOAD命令。（它保證可可以呼叫 EVALSHA 而不會有失敗的風險）。

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

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

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

畢竟Redis程序和測試基準benchmark在相同的機器上執行，並且這是沒有任何實際的延遲和真實的網路參與，不就是訊息通過記憶體從一個地方拷貝到另一個地方麼？原因是程序在作業系統中並不是一直執行。真實的情景是系統核心排程，排程到程序執行，它才會執行。比如測試基準benchmark被允許執行，從Redis Server中讀取響應內容（與最後一次執行的命令相關），並且寫了一個新的命令。這時命令將在迴環網路的通訊端中，但是為了被Redis Server讀取，系統核心需要排程Redis Server程序（當前正在系統中掛起），周而復始。所以由於系統核心排程的機制，就算是在迴環網路中，仍然會涉及到網路延遲。簡言之，在網路伺服器中衡量效能時，使用迴環網路測試並不是一個明智的方式。應該避免使用此種方式來測試基準。