引言

Redis是一種基于客戶端-服務端模型以及請求/響應協議的TCP服務。

這意味著通常情況下一個請求會遵循以下步驟：

• 客戶端向服務端發送一個查詢請求，并監聽Socket返回，通常是以阻塞模式，等待服務端響應。
• 服務端處理命令，并將結果返回給客戶端。

因此，例如下面是4個命令序列執行情況：

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

?RTT (Round Trip Time - 往返時間). 當客戶端需要在一個批處理中執行多次請求時很容易看到這是如何影響性能的（例如添加許多元素到同一個list，或者用很多Keys填充數據庫）。

例如，如果RTT時間是250毫秒（在一個很慢的連接下），即使服務器每秒能處理100k的請求數，我們每秒最多也只能處理4個請求。

一、Redis 管道（Pipelining）

服務器能實現即使舊的請求還未被響應，新的請求也可以被處理，這就是管道的含義。它是一種幾十年來廣泛使用的技術。例如許多POP3協議已經實現支持這個功能，大大加快了從服務器下載新郵件的過程。

Redis很早就支持管道（pipelining）技術，因此無論你運行的是什么版本，你都可以使用管道（pipelining）操作Redis。

例如：

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

非常明確的，用管道順序操作的第一個例子如下：

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

注意：使用管道發送命令時，務器將被迫回復一個隊列答復，占用很多內存。

所以，如果你需要發送大量的命令，最好是把他們按照合理數量分批次的處理，例如10K的命令，讀回復，然后再發送另一個10k的命令，等等。這樣速度幾乎是相同的，但是在回復這10k命令隊列需要非常大量的內存用來組織返回數據內容。

?

總結

以上是生活随笔為你收集整理的Redis 实用技术——Pipeline的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。