引言

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

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

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

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

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

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

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

一、Redis 管道（Pipelining）

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

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

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

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

?

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。