Redis是一種典型的基於C/S模型的TCP服務。在客戶端與服務器端的通訊過程中，通常都是客戶端率先發起請求，服務器在接收到請求後執行相應的任務，最後再將獲取的數據或處理結果以應答的方式發送給客戶端。在此過程中，客戶端都會以阻塞的方式等待服務器返回的結果。
在每一對請求與應答的過程中，我們不得不承受網絡傳輸所帶來的額外開銷。通常將這種開銷稱爲RTT（Round Trip Time）。現在我們假設每一次請求與應答的RTT爲250毫秒，而服務器可以再一秒內處理100k數據，可結果則是服務器每秒最多處理4條請求。
要想解決這個性能問題，如何進行優化？
將上面的同步應答方式改造爲基於命令管線的異步應答方式，客戶端在發送命令後，不用立刻等待來着服務器的應答，而是繼續發送後面的命令。在命令發送完畢後，再一次性的讀取之前所有命令的應答。這樣便也可節省了同步方式中的RTT的開銷。
如果Redis服務器發現客戶端的請求是基於管線的，那麼服務器端在接收到請求並處理後，會將每條命令的應答數據存入隊列，之後再發送到客戶端。
