更多技術文章，請關注我的個人博客 www.immaxfang.com 和小公眾號 Max的學習札記，

Redis 客戶端和服務端之間是采用 TCP 協議進行通信的，是基于 Request/Response 這種一問一答的模式，即請求一次回應一次，

普通模式

我們先來看下普通模式下，一條 Redis 命令的簡要執行程序：

• 客戶端發送一條命令給 redis-server，阻塞等待 redis-server 應答
• redis-server 接收到命令，執行命令
• redis-server 將結果回傳給客戶端

下面我們來簡要了解下一個完整請求的互動程序，

1. 客戶端呼叫 write() 將訊息寫入作業系統為 socket 分配的 send buffer 中
2. 作業系統將 send buffer 中的內容發送到網卡，網卡通過網關路由把內容發送到服務器網卡
3. 服務器網卡將接受到的訊息寫入作業系統為 socket 分配的 recv buffer
4. 服務器行程呼叫 read() 從 recv buffer 中讀取訊息進行處理
5. 處理完成之后，服務器呼叫 write() 將回應內容發送的 send buffer 中
6. 服務器將 send buffer 中的內容通過網卡，發送到客戶端
7. 客戶端作業系統將網卡中的內容放入 recv buffer 中
8. 客戶端行程呼叫 read() 從 recv buffer 中讀取訊息
   

普通模式的問題

我們來想一下，這種情況下可能導致什么問題，
如果同時執行大量的命令，那對于每一個命令，都要按上面的流程走一次，當前的命令需要等待上一條命令執行應答完畢之后，才會執行，這個程序中會有多次的 RTT ，也還會伴隨著很多的 IO 開銷，發送網路請求等，每條命令的發送和接收的程序都會占用兩邊的網路傳輸，
簡單的來說，每個命令的執行時間 = 客戶端發送耗時 + 服務器處理耗時 + 服務器回傳耗時 + 一個網路來回耗時，
在這里，一個 網路來回耗時（RTT） 是不好控制的，也是不穩定的，它的影響因素很多，比如客戶端到服務器的網路線路是否擁堵，經過了多少跳，還有就是 IO 系統呼叫也是耗時的，一個 read 系統呼叫，需要從用戶態，切換到內核態，上文我們講述一個命令的請求程序時多次降到 read 和 write 系統呼叫，
可以說一個命令的執行時間，很大程度上受到它們的限制，

pipeline 模式

有沒有什么方法來解決這種問題呢，
第一種方法，就是利用多執行緒機制，并行執行命令，
第二種方法，呼叫批量命令，例如 mget等，一次操作多個鍵，
很多時候我們要執行的命令并不是一樣的命令，而是一組命令，這個時候就無法使用類似 mget這樣的批量命令了，那還有其他的方法嗎？
回想一下，我們初學編程的時候，老手都會告訴我們，不要在回圈里面做查詢，我有一個 books 串列資料，要根據 book_id 查詢它們的 price，如果我們回圈 books 串列，在每次回圈里面取查詢單個 book_id 的 price，那性能肯定是不理想的，一般我們的優化方式是將多個 book_id 取出來，一次性去查多個 book_id 的 price，這樣性能就有明顯的提示，即將多次小命令中的耗時操作合并到一次，從而減少總的執行時間，
類似的，Redis pipeline 出現了，一般稱之為管道，它允許客戶端一次可以發送多條命令，而不用像普通模式那樣每次執行一個小命令都要等待前一個小命令執行完，服務器在接收到一堆命令后，會依次執行，然后把結果打包，再一次性回傳給客戶端，
這樣可以避免頻繁的命令發送，減少 RTT，減少 IO 呼叫次數，前面已經介紹了，IO 呼叫會涉及到用戶態和內核態之間的切換，在高性能的一些系統中，我們都是盡可能的減少 IO 呼叫，
簡要流程如下圖：

• pipeline 的優點
  • 減少 RTT
  • 減少 IO 呼叫次數
• 基本使用

Pipeline pipeline =jedis.pipelined();

for(int i = 0; i < 100; i++){
    pipeline.rpush("rediskey", i + "");
}

pipeline.sync()

總結一下 pipeline 的核心，就是客戶端將一組 Redis 命令進行組裝，通過一次 RTT 發送給服務器，同時服務器再將這組命令的執行結果按照順序一次回傳給客戶端，

pipeline 注意問題

雖然 pipeline 在某些情況下會帶來不小的性能提升，但是，我們在使用的時候也需要注意，

• pipeline 中的命令數量不宜過多，

客戶端會先將多個命令寫入記憶體 buffer 中（打包），命令過多，如果是超過了客戶端設定的 buffer 上限，被客戶端的處理策略處理了（不同的客戶端實作可能會有差異，比如 jedis pipeline ，限制每次最大的發送位元組數為 8192，緩沖區滿了就發送，然后再寫緩沖，最后才處理 Redis 服務器的應答），如果客戶端沒有設定 buffer 上限或不支持上限設定，則會占用更多的客戶端機器記憶體，造成客戶端癱瘓，官方推薦是每次 10k 個命令，
建議做好規范，遇到一次包含大量命令的 pipeline，可以拆分成多個稍小的 pipeline 來完成，

• pipeline 一次只能運行在一個 Redis 節點上，一些集群或者 twemproxy 等中間件使用需要注意，

在集群環境下，一次 pipeline 批量執行多個命令，每個命令需要根據 key 計算槽位，然后根據槽位去特定的節點上去執行命令，這樣一次 pipeline 就會使用多個節點的 redis 連接，這種當前也是不支持的，

• pipeline 不保證原子性，如要求原子性，不建議使用 pipeline

它僅是將多個命令打包發送出去而已，如果中間有命令執行例外，也會繼續執行剩余命令，

pipeline 與批量操作 mget 等區別

其實 meget和 pipeline 優化的方向是一致的，即多個命令打包一次發送，減少網路時間，但是也是有區別的，

• mget等的場景是一個命令對應多個鍵值對，而 pipeline 一般是多條命令（不同的命令）
• mget操作是一個原子操作，而 pipeline 不是原子操作
• mget是服務端實作，而 pipeline 是客戶端和服務端共同實作
  

pipeline 與事務的區別

這兩者關注和解決的問題不是一個東西，原理也不一樣，

• pipeline 是一次請求，服務端順序執行，一次回傳，而事務是多次請求（先 multi，再多個操作命令，最后 exec），服務端順序執行，一次回傳
• pipeline 關注的是 RTT 時間和 IO 呼叫，事務關注的是一致性問題
  

總結

本文主要講了多命令執行時耗時問題，以及 pipeline 的解決方法，和其簡單的原理，以及注意點，今天的學習就到這里，改天我們接著肝，

標籤：其他

上一篇：微服務架構 | 如果是你，你會怎么拆？

下一篇：一種基于柔性事務的分布式事務解決方案設計探究