Redis客戶端通過TCP連接或者類似的面向流的連接來和服務器端進行通訊
通常情況下：客戶端發送命令到服務器端，並等待服務器端的返回；服務器端接收到命令，並完成響應操作，發送處理結果數據給客戶端；這樣就完成了完成了一次請求/響應
在我們使用Redis時，客戶端一般一次只發送一個命令，舉個例來說：
這樣的模式適用於很多的業務場景。比如說我們在獲取數據時一般是阻塞的，自然需要等待服務器端返回數據才能進行下一步操作。又比如說有多個客戶端或者說有多個線程的情況下，這一邊所存的數據很有可能在下一刻便會被另一邊用到，所以命令能越快發送就越好
當然凡事都有特例，在一些特殊的業務中，我們可能需要存儲大量的數據，使用到許多的命令。在這種情況下，客戶端再一條命令一條命令的發送就顯得不太經濟了，如果批量發送命令會不會提高效率，減省時間？
很容易發現如果一次性發送多條命令，大量減少了IO操作。要知道IO系統調用，無論是read還是write，都是比較費時的操作，每一次IO系統調用，在操作系統內都需要涉及用戶態和內核態的切換。原本n條命令在客戶端需要n*2次IO系統調用（read&write），現在如果是使用流水線技術，將多條命令一次性發送，就只需要2次IO系統調用
如果向更深層次分析，如果客戶端向服務器端，一次只發送一條命令，那麼可以吧一條命令看作一個數據包，它在網絡中的傳輸如下：
從圖中我們可以看出，客戶端發送數據包到服務器端返回數據包給客戶端，其中所消耗的時間稱爲往返時間（Round Trip Time-RTT），往返時間的長短取決於網絡線路暢通與否，但即使是使用迴環網卡，和高效的CUP處理速度相比，仍然是一個很長的時間。當我們使用流水線技術時，就會發現大大的減少了RTT，這纔是流水線技術提升性能的最主要原因
同時我們也會發現流水線技術對於緩存的花費是很大的，在客戶端，需要將多條命令先緩存起來，存儲了一定數量以後才一起發送給服務器端。在服務器端，這需要將克虎發來的多條命令緩存起來，一條命令一條命令的處理，同時還需存儲處理後的結果，最後將多條結果返回給客戶端。所以在編寫代碼時需要同時考慮內存開銷和時間開銷，使批量發送的命令數量在合理的範圍內
問題1：在Redis中流水線（pipeline）和事務（Transaction）的區別？
-
就實現上來說：實現事務只需要服務器端的支持，開啓事物之後，服務器端會存儲客戶端的命令，最後一次性執行；實現pipline則需要客戶端和服務器端共同的支持，客戶端一次性發送多個命令，服務端一次性響應多個命令
-
就功能上來說：事務是一個單獨的隔離操作，並且具有原子性；pipeline則是爲了減少RTT以及IO操作，提升性能