redis管道 1.redis管道介紹 redis採用的是CS架構，客戶端與伺服器端通過tcp協議進行連接通信，因此無論是發出請求還是接收響應，都必須經過網路傳輸。在tcp連接過程中，客戶端和伺服器端是通過阻塞式的一問一答方式進行通信的，即客戶端必須接收到服務端完整的響應，才能進行後續請求。 有時我 ...
redis管道
1.redis管道介紹
redis採用的是CS架構，客戶端與伺服器端通過tcp協議進行連接通信，因此無論是發出請求還是接收響應，都必須經過網路傳輸。在tcp連接過程中，客戶端和伺服器端是通過阻塞式的一問一答方式進行通信的，即客戶端必須接收到服務端完整的響應，才能進行後續請求。
有時我們會在短時間內發送大量互不依賴的命令(例如:後執行的命令不需要使用前面返回的結果)。由於網路傳輸不可避免的會造成一定的延遲，特別是在跨機器遠程訪問redis的時候，如果使用常規的方式，一條命令對應一次請求和響應的話，大量命令累計的延遲會顯得很高。redis的設計者考慮到這一點，在底層的通信協議上，通過支持"管道(pipeline)"來解決這一問題。
簡單示例：
普通命令：3次請求/響應
client：INCR num001；
server：1；
client：INCR num001；
server：2；
client：INCR num001；
server：3；
管道命令：1次請求/響應
client：INCR num001；
client：INCR num001；
client：INCR num001；
server：1；
server：2；
server：3；
redis管道可以在一次tcp的請求中同時發送多條命令，並且將響應結果一次性的返回給客戶端。對於既定數量的命令請求，redis管道通過減少客戶端和伺服器端的通信次數，來達到減少通信傳輸中往返時間的目的，提高效率。
2.redis管道註意事項
1.由於redis的管道要求伺服器一次性的將請求返回，因此redis服務端只能將靠前命令處理的結果暫時緩存起來。如果管道一次響應的數據量過多(大規模查詢之類的)，可能會對redis伺服器的記憶體造成較大的壓力。因此，管道批量處理的命令數量並不是越多越好，需要結合實際需求，合理的決定一次管道批處理命令的數量。
2.redis的管道在客戶端通常會設置一個命令緩衝區來存儲即將被批量發送的命令，當緩衝區被填滿時，才會一次性的將緩衝區的命令發送。這裡需要註意的一點是：當業務上的同一批命令使用管道進行請求時，如果最後剩餘的命令無法填滿緩衝區，如果不使用相應的flush操作，這些命令將不會被髮送出去，而是保留在命令緩衝區等待新的命令來填滿緩衝區。
3.redis管道總結
redis的管道可以將多個命令打包，一次性的發送給伺服器端處理，當命令之間不存在依賴關係時，相比於一條命令一次請求的普通操作方式，管道的操作幾乎是對使用者透明的。
和redis的事務類似，redis管道能完成的操作也能夠被更加靈活的redis腳本實現，但是腳本的可讀性不強、可維護性差。個人認為，如果批量處理的命令之間不存在依賴關係時，優先使用管道；反之，則只能使用腳本了。
redis的管道技術在客戶端和伺服器端的實現還有很多細節值得探討，限於個人能力，就不展開說明瞭。
