Redis管道

背景

Redis是一種基於客戶端-服務端模型以及請求/響應協議的TCP服務。一個請求會遵循以下步驟：

1 客戶端向服務端發送命令分四步(發送命令→命令排隊→命令執行→返回結果)，並監聽Socket返回，通常以阻塞模式等待服務端響應。

2 服務端處理命令，並將結果返回給客戶端。

上述兩步稱為：Round Trip Time(簡稱RTT,數據包往返於兩端的時間)，問題筆記最下方

如果同時需要執行大量的命令，那麼就要等待上一條命令應答後再執行，這中間不僅僅多了RTT（Round Time Trip），而且還頻繁調用系統IO，發送網路請求，同時需要redis調用多次read()和write()系統方法，系統方法會將數據從用戶態轉移到內核態，這樣就會對進程上下文有比較大的影響了，性能不太好，o(╥﹏╥)o

如何優化頻繁命令往返造成的性能瓶頸——管道

Pipeline是為瞭解決RTT往返時，僅僅是將命令打包一次性發送，對整個Redis的執行不造成其它任何影響。是批處理命令變種優化措施類似於Redis的原生批命令（mget和mset）

案例

小結

Pipeline與原生批量命令對比：

1. 原生批量命令是原子性（如mset，mget），Pipeline是非原子性。

2. 原生批量命令一次只能執行一種命令，Pipeline支持批量執行不同的命令。

3. 原生批量命令是服務端實現，而Pipeline需要服務端與客戶端共同完成。

Pipeline與事物對比：

1. 事務具有原子性，管道不具有原子性。

2. 管道一次性將多條命令發送到伺服器，事務是一條一條的發，事務只有在接收到exec命令後才會執行，管道不會。

3. 執行事務時會阻塞其他命令的執行，而執行管道中的命令時不會。

使用PIpeline註意事項：

• PIpeline緩衝的指令只是會依次執行，不保證原子性，如果執行中指令發生異常，將會繼續執行後續的指令。

• 使用PIpeline組裝的命令個數不能太多，不然數據量過大客戶端阻塞的時間可能過久，同時服務端此時也被迫恢復一個隊列的答覆，占用很多記憶體。