redis單個請求與批量操作對比
??Redis是一種基于客戶端-服務(wù)端模型以及請求/響應(yīng)協(xié)議的TCP服務(wù)乏沸。
這意味著通常情況下一個請求會遵循以下步驟：
● 客戶端向服務(wù)端發(fā)送一個查詢請求怪瓶，并監(jiān)聽Socket返回缕陕，通常是以阻塞模式，等待服務(wù)端響應(yīng)挂捻。
● 服務(wù)端處理命令，并將結(jié)果返回給客戶端。
所以在大批量操作數(shù)據(jù)時揍诽，很容易消耗IO，導(dǎo)致代碼性能差栗竖，執(zhí)行時間長暑脆。
??Redis 管道技術(shù)可以在服務(wù)端未響應(yīng)時，客戶端可以繼續(xù)向服務(wù)端發(fā)送請求狐肢，并最終一次性讀取所有服務(wù)端的響應(yīng)添吗。請求流程對比如下圖：
管道的特點(diǎn)
??pipeline并不是原子性的，中間可能會存在部分失敗的情況份名，也就是說不能保證每條命令都能執(zhí)行成功碟联，這個是需要注意的妓美，如果需要每條命令都執(zhí)行成功，我們在批量執(zhí)行過程中需要監(jiān)控執(zhí)行數(shù)量和返回的成功數(shù)量是否一致鲤孵。
??同時壶栋，當(dāng)一次性進(jìn)行大量的數(shù)據(jù)批量操作時，由于數(shù)據(jù)量過大普监，導(dǎo)致redis執(zhí)行超時或其他的情況贵试，所以這塊最好事先測試自己的數(shù)據(jù)大小，決定多少數(shù)據(jù)適合批量一次性操作凯正，類似采用分頁批量操作毙玻。
管道適用場景
??pipeline適合于什么樣的場景使用呢？一般是對業(yè)務(wù)場景不需要實(shí)時性和準(zhǔn)確性的系統(tǒng)廊散，保證大部分操作成功即可桑滩。如果想讓操作一定成功，需要一定檢測和補(bǔ)償機(jī)制奸汇，這里補(bǔ)償機(jī)制一般是根據(jù)批量操作的返回的狀態(tài)和成功數(shù)量和批量操作的對比來進(jìn)行補(bǔ)償施符，如果有部分失敗，就轉(zhuǎn)向單個redis請求操作擂找，但是此處需要做好監(jiān)控戳吝，避免批量全部失敗，降級為單個執(zhí)行贯涎，這樣性能損耗將更大听哭，這是需要極度避免的。
