背景以及概念:
原始查詢，我們主要通過調用redis客戶端執行單get,set操作，每次查詢都將新建連接，實際項目的耗時主要來源於網絡耗時，當數據較少，單次查詢/修改性能影響不明顯，當命令達W級別，單命令操作耗時影響很大；redis提供了管道技術，正好可以彌補這個缺點，
redis-pipeline 技術可以在服務端未響應時，客戶端可以繼續向服務端發送請求，並最終一次性讀取所有服務端的響應。
特點: 有效的減少了RTT和redis連接數，同時也減少了IO調用次數（IO調用涉及到用戶態到內核態之間的切換）。
****
內核態用戶態：https://blog.csdn.net/lxlmycsdnfree/article/details/78776544
https://zhuanlan.zhihu.com/p/69554144
****
pipeline並未保證原子性。即同一個pipeline中的命令在redis-server被執行的順序可以保證，但不保證其中不會穿插其餘的客戶端請求的命令。 可以通過redis的slowlog查看命令的執行順序，以驗證此特點
每次Pipeline組裝的命令個數不能沒有節制，否則一次組裝Pipeline數據量過大，一方面會增加客戶端的等待時間，另一方面會造成一定的網絡阻塞，可以將一次包含大量命令的Pipeline拆分成多次較小的Pipeline來完成。
使用管道發送命令時，服務器將被迫回覆一個隊列答覆，佔用很多內存。所以，如果你需要發送大量的命令，最好是把他們按照合理數量分批次的處理。 例如10K的命令，讀回覆，然後再發送另一個10k的命令，等等。這樣速度幾乎是相同的，但是在回覆這10k命令隊列需要非常大量的內存用來組織返回數據內容。
redis_pipeline模型
client首先把執行的命令存放在緩衝區（client-buffer），最後統一執行，但是有一種情況是，緩衝區（client-buffer）的大小是有限制的，比如Jedis，限制爲8192，超過了，則刷緩存，發送請求到Redis，但是jedis不會去處理Redis的應答，如上圖所示那樣。
Redis的Pipeline和Transaction（Multi）不同，Transaction會存儲客戶端的命令，最後一次性執行，而Pipeline則是處理一條響應一條。 但是這裏卻有一點，就是客戶端會並不會調用read去讀取socket裏面的緩衝數據。 這也就造就了，如果Redis應答的數據填滿了該接收緩衝（SO_RECVBUF），那麼客戶端會通過ACK，WIN=0（接收窗口）來控制服務端不能再發送數據， 那樣子，數據就會緩衝在Redis的客戶端應答列表裏面。所以需要注意控制Pipeline的大小
例如圖中的，value1,value2,value3假設client接收到了此response，（假設）並保存在client-receive-buffer（客戶端 接收緩衝區），且剛好佔滿client-receive-buffer。
但是，client並不會去read，且 client-receive-buffer 被佔滿，client會通過 ack,win=0通知redis-server不要再發送響應數據。因此要控制pipeline的大小。
核心點：pipeline管道模式，較少了ttl，io切換的耗時，使批量命令的執行相對提高了N倍。
細節點：server對pipeline的命令結果進行緩存處理，會消耗很多內存，同時client執行命令後，結果會緩存在client-revice-buffer中，如果緩存滿了，通知server停止發送數據，因此要控制好每次pipeline的大小，保持效率最高；
常見誤區：pipeline每次命令執行多少對於速度不會影響，因爲pipeline是長連接的，因此10k命令分爲100此0.1k命令並不會造成速度的減慢。
實際項目優化案列：
實際項目耗時:
client訪問trpc服務：server查詢redis(pipeline方式),1w級別耗時1.17s(包括瀏覽器與sever的2RTT,server與redis的2RTT)以及linux的IO，線程操作；
相比下,原始client模型，單次訪問，單次回覆的模式，耗時11.7s
優化：相比10倍，隨着數據的增多，優化效率更加明顯；
具體代碼沒有貼出，涉及私密；
piple通道的使用可以參考官網的文檔，進行編寫；