redis單個請求與批量操作對比
Redis是一種基於客戶端-服務端模型以及請求/響應協議的TCP服務。 這意味著通常情況下一個請求會遵循以下步驟： ● 客戶端向服務端傳送一個查詢請求，並監聽Socket返回，通常是以阻塞模式，等待服務端響應。 ● 服務端處理命令，並將結果返回給客戶端。 所以在大批量運算元據時，很容易消耗IO，導致程式碼效能差，執行時間長。 Redis 管道技術可以在服務端未響應時，客戶端可以繼續向服務端傳送請求，並最終一次性讀取所有服務端的響應。請求流程對比如下圖：
管道的特點
pipeline並不是原子性的，中間可能會存在部分失敗的情況，也就是說不能保證每條命令都能執行成功，這個是需要注意的，如果需要每條命令都執行成功，我們在批量執行過程中需要監控執行數量和返回的成功數量是否一致。 同時，當一次性進行大量的資料批量操作時，由於資料量過大，導致redis執行超時或其他的情況，所以這塊最好事先測試自己的資料大小，決定多少資料適合批量一次性操作，類似採用分頁批量操作。
管道適用場景
pipeline適合於什麼樣的場景使用呢？一般是對業務場景不需要實時性和準確性的系統，保證大部分操作成功即可。如果想讓操作一定成功，需要一定檢測和補償機制，這裡補償機制一般是根據批量操作的返回的狀態和成功數量和批量操作的對比來進行補償，如果有部分失敗，就轉向單個redis請求操作，但是此處需要做好監控，避免批量全部失敗，降級為單個執行，這樣效能損耗將更大，這是需要極度避免的。