Redis批量操作詳解及效能分析

指令執行開銷

(高併發下)資源競爭和系統排程排程開銷

管道(pipelining)

事務(transaction)

基於事務的管道(transaction in pipelining)

mset(適用於string型別)

hmget(適用於hash型別)

hmset(適用於hash型別)

批量命令在key數目巨大時存在rrt與key數目成比例放大的效能衰減，會導致單例項響應效能(rrt)嚴重下降，更多分析請參考之前的文章。

中介軟體分片場景下，codis等中介軟體分片服務中，會將mget/mset的多個key拆分成多個命令發往不同得redis例項，事實上已經喪失了mget強大的聚合執行能力。

cluster場景下，mget僅支援單個slot內批量執行，否則將會獲得乙個錯誤資訊。

jedis jedis = pool.getresource();
tryfinally

$ printf "incr x\r\nincr x\r\nincr x\r\n" | nc localhost 6379 :1:2 :3$ printf "get x\r\ndel x\r\n" | nc localhost 6379$13

:1

可以使用各種redis命令，使用更靈活

客戶端一般會將命令打包，並控制每個包的大小，在執行大量命令的場景中，可以有效提公升執行效率。

由於所有命令被分批次傳送到伺服器端執行，因此相比較事務型別的操作先逐批發送，再一次執行（或取消），管道擁有微弱的效能優勢。

中介軟體分片，一般由中介軟體對管道進行拆分和結果合併

cluster場景下，對pipeline的支援等同於單機，可以將同一節點中不同slot分片的節點通過批量操作一次執行，但是從實踐來說，情況更加複雜，除非有充分的理由，否則不建議 (將來jedis可能會支援對同一slot的所有key支援pipeline)。

jedis jedis = pool.getresource();
try finally 
} catch (exception e) finally

單個事務的所有命令，或者被全部執行，或者乙個也不會被執行，因此事務保證了redis操作的原子性。命令exec觸發事務中所有命令的執行，因此如果乙個client在事務上下文中丟失了連線，那麼不會有任何一條命令被執行；相反如果client已經呼叫了exec，那麼所有命令都會被執行。

watch

unwatch

exec

discard

可以使用watch提供的樂觀鎖機制保證命令執行的排他性。

在keys競爭激烈時，watch提供的樂觀鎖由於競爭過多而效能低下，應該盡量避免。

redis cluster支援transaction，但是前提是transaction涉及的所有key都屬於同一hash slot。

jedis jedis = pool.getresource();
try finally 
} catch (exception e) finally

jedis jedis = pool.getresource();
try finally 
} catch (exception e) finally

測試過程：

使用set/mset/pipeline/transaction/transaction in pipeline這五種方式分別重新設定所有key的值，記錄各自的執行時長

使用get/mget/pipeline/transaction/transaction in pipeline這五種方式分別遍歷所有key的值，記錄各自的執行時長110

setpipeline好於transaction in pipeline，因為事務會導致命令入列和出列會稍許浪費cpu時間

transaction in pipeline微弱領先於transaction，但是幾乎沒有區別，可以理解為pipeline在命令傳輸上更有效率。

總得來說，在批量模式下，四種操作都比普通的get/set效能上有幾大的提公升。

在當前生產環境中使用較多的redis cluster環境中，上述四種批量操作的使用場景都比較有限，其中transaction不支援，pipeline建議僅用於單slot且目前支援的客戶端很少，mget/mset也僅僅可以操作於單slot中的key。