管道

• 開始接觸Redis時候，對應Redis管道有一個錯誤認識，任務是redis服務器提供的一種特別的技術，有了這種技術可以加速Redis的存取效率，但是實際上Redis的管道計算（Pipeline）本身是客戶端提供的技術，與服務端無關。

Redis消息交互

• 當我們使用客戶端對Redis服務器發送消息指令，客戶端將請求發送給服務器，服務器處理完后響應信息返回給客戶端，需要花費一個網絡數據報的來回時間。
• 如果聯系執行多條指令，會花費多個網絡數據報的來回時間，如下圖

• 多條指令的時候，客戶端經歷了寫–讀--寫–讀四個操作完成整改兩條指令。
• 假如我們跳轉順序，編程：寫–寫--讀–讀，那么同樣是兩個指令是不是可以將寫入信息打包發送，讀取的信息打包返回，如下圖：
  
• 這便是Redis客戶端管道操作的本質作用，服務器并沒有區別對待，還是走一條消息，一次執行，回復一條消息的正常流程，客戶端通過對管道列表改變讀寫順序就可以大幅度節省IO時間。管道中指令越多越好。

深入理解管道工作流程

• 上一節中有一個完整的Redis指令請求的流行，我們拿來，如下

• 如上劉沖中我們逐步分析作用

Client調用write將消息寫入操作系統內核為套接字準備的發送緩沖區send buffer中

Client操作系統內核將發送緩沖的內容發送到王卡NIC，王卡硬件將數據通過“網絡路由”送的服務器的王卡NIC

服務器操作系統內核將王卡數據放到內核為套接字分配的接收緩沖recv buffer中

服務器進程調用read從接收緩沖中取出消息進行處理

服務器進程調用write將響應消息寫道內核為套接字分配的發送緩沖send buffer中

服務器操作系統內核發送緩沖區中的內容到王卡，服務器網卡將數據通過“網絡路由”送到客戶端的網卡

客戶端操作系統內核將網卡中數據寫道內核為套接字分配的接收緩沖區 recv buffer中

客戶端進程調用read從接收緩沖區中取出消息并返回給上層業務邏輯進行處理

• 以上是所有步驟，其中5 ~ 8 和 1 ~ 4 是一樣的，只不過方向反過來，一個請求一個響應

• 我們從上面步驟看出

  • 服務器的write操作不需要等對方收到消息才返回，他實際上只負責將數據寫入到本地操作系統內核的發送緩沖區中，生效的由操作系統自己將數據發送到客戶端機器，如果緩沖區滿那么需要等待緩沖區空閑，這個才是寫操作IO的耗時
  • 客戶端的read操作并不是從服務器直接拉去數據，他實際上只負責將數據從本地操作系統的內核的接收緩沖區取出數據，如果緩存區是空的，那么需要等待數據到來，這個才是read操作IO的實際時間

• 案例，value = RedisDao.get(key)

  • 客戶端將指令寫入緩沖區，返回，幾乎無消耗
  • 客戶端read需要等待消息經過網絡路由到目標機器處理后的響應消息，在回送到當前的內核讀緩沖才可以返回，這個是網絡的真正開銷

• 如上案例也可以看出，對于管道來說，連續的write操作根本沒有耗時，之后第一個read操作會等待一個網絡來回的的開銷，然后后續所有響應消息也會打包一起回到內核的讀緩沖區，效率大增

上一篇：Redis高效性探索–線程IO模型，通信協議
下一篇：Redis持久化-深入理解AOF，RDB

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的Redis高效性探索--管道的全部內容，希望文章能夠幫你解決所遇到的問題。

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