Redis 是一種基于客戶端-服務端模型以及請求/響應協議的 TCP 服務。這意味著通常情況下一個請求會遵循以下步驟：

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

一個 client 可以通過一個 socket 連接發起多個請求命令。

每個請求命令發出后 client 通常會阻塞并等待 redis 服務處理，redis 處理完后請求命令后會將結果通過響應報文返回給 client 。

客戶端和服務端通過網絡進行連接。這樣的連接可能非常快，也可能非常慢（在廣域網上經過多個結點才能互通的兩個主機）。但是無論是否存在網絡延遲，數據包從客戶端傳輸到服務端，以及客戶端從服務端獲得相應都需要花費一些時間。這段時間就成為往返時延( Round Trip Time)。

因此當客戶端需要執行一串請求的時候，很容易看出它對性能的影響（例如往同一個隊列中加入大量元素，或者往數據庫中插入大量的鍵）。如果RTT時長為250毫秒（在基于廣域網的低速連接環境下），即使服務器每秒可以處理 10 萬個請求，但是實際上我們依然只能每秒處理最多4個請求。
如果處于一個回路網絡中，RTT 時長則相當短（我的主機 ping 127.0.0.1時只需要0.044ms），但是如果你執行一大串寫入請求的時候，還是會有點長。

1. 管道

一個請求/相應服務可以實現為，即使客戶端沒有讀取到舊請求的響應，服務端依舊可以處理新請求。通過這種方式，可以完全無需等待服務端應答地發送多條指令給服務端，并最終一次性讀取所有應答。管道技術最顯著的優勢是提高了 redis 服務的性能。

通過 pipeline 方式當有大批量的操作時候。我們可以節省很多原來浪費在網絡延遲的時間。需要注意到是用 pipeline 方式打包命令發送，redis 必須在處理完所有命令前先緩存起所有命令的處理結果。打包的命令越多，緩存消耗內存也越多。所以并是不是打包的命令越多越好。具體多少合適需要根據具體情況測試。

如果連續執行多條指令，那就會花費多個網絡數據包來回的時間。如下圖所示。

調整讀寫順序，使得兩個連續的寫操作和兩個連續的讀操作總共只會花費一次網絡來回，就好比連續的 request 操作合并了，連續的 response 操作也合并了一樣。

這便是管道操作的本質，它并不是服務器的什么特性，服務器根本沒有任何區別對待，還是收到一條消息，執行一條消息，回復一條消息的正常的流程。客戶端通過對管道中的指令列表改變讀寫順序就可以大幅節省 IO 時間，從而提升性能。

總結

以上是生活随笔為你收集整理的Redis 笔记（15）— 管道 pipeline（客户端将批量命令打包发送用来节省网络开销）的全部內容，希望文章能夠幫你解決所遇到的問題。

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