redis是乙個響應式的服務，當client傳送乙個請求後，就處於堵塞狀態等待redis返回結果。
這樣一次命令消耗的時間就包含三個部分：請求從client到server的時間、結果從server到client的時間和命令真正執行時間，前兩個部分消耗的時間總和稱為rtt（round trip time）。當client與server存在網路延時時，rtt就可能會非常大，這樣就會導致效能問題。
管道（pipeline）就是為了改善這個情況的。利用管道，client能夠一次性傳送多個請求而不用等待server的響應，待全部命令都傳送完後再一次性讀取服務的響應，這樣能夠極大的減少rtt時間從而提公升效能。
以下這個樣例。在本地分別以普通請求和管道對乙個鍵呼叫2000次incr命令的測試。
public static void withpipeline()
responser = p.get("thekey");
p.sync();
system.out.println(r.get());
} finally
}public static void withoutpipeline()
system.out.println(jedis.get("thekey"));
} finally
}}//輸出結果
2000
without pipeline takes: 183 ms.
2000
with pipeline takes: 47 ms.
結果非常直觀的反映出兩者的區別。要知道這是在本地測試，差點兒不存在網路延時的問題。假設是在不同的網段測試的話，效果會更明顯。
儘管管道在一定程度上對效能有所提公升，可是在使用時一點要注意。每乙個命令的返回結果是先被快取在server端的，最後一次性返回給client。假設一次批量提交涉及大量的返回結果，可能會導至server的記憶體溢位。這在生產環境是致命的。一次批次處理多少量，最好在設計階段做出合理評估。
最後，管道僅僅是乙個方案。並不意味著在不論什麼時候都要盡可能的使用它。而是應該結合考慮網路延遲時間、業務涉及的請求量等等因素綜合考慮。畢竟建立管道本身也會有一定的消耗。
深入淺出redis事件框架
eventloop typedef struct aeeventloop aeeventloop 註冊的檔案事件 typedef struct aefileevent aefileevent 發生的檔案事件 typedef struct aefiredevent aefiredevent 時間事件 ...
深入淺出MySQL筆記（三）
本筆記為學習該書所記，便於複習。包含第五 六章筆記。常用函式與圖形化工具的使用。toc 常用字串函式 concat s1,s2.sn 連線s1,s2.sn為乙個字串 insert str,x,y,instr 將字串str從第x位置開始，y個字元長的子串替換為字串instr lower str 將字串...
《深入淺出MFC》筆記（三）
1,win32 console程式示例 include include include include const int filemax 300 allow max.300 files in each directory typedef struct destfile destfile typed...