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的管道技術在客戶端和服務器端的實現還有很多細節值得探討，限於個人能力，就不展開說明了。