·背景

Redis以"快、準、狠"而著稱，除了其主-從模式略失光彩（主從模式更多是被以訛傳訛，3.0依舊在測試中），大部分的應用可謂尖兵利器。在一些常規(guī)寫的時候，MSET和HMSET也是被大家最推崇的模式之一，之前網(wǎng)上有篇文章說到M的極限在200以后會趨于飽和，那么究竟是不是這樣，今天無聊做了下測試。

·測試場景

·配置：Lenovo E49 Corei5/VM9/CentOS 6(2.6)/2C/2G/10GDISK/純單機，走127.0.0.1

·數(shù)量：測試K-V量100萬條 ，變量為M和C。M為一次帶上的K-V條數(shù)，C為輪訓次數(shù)（類同網(wǎng)絡開閉成本），兩者乘積M·C=1000000。

·腳本：測試腳本，SHELL連接redis-cli，如下。雙開，撐爆CPU。

A=1;
while [ $A -lt 20000 ]
do
redis-cli -p 7000 MSET 1 2 2 2 3 2 4 2 5 2 6 2 7 2 8 2 9 2 10 2 11 2 12 2 13 2 14 2 15 2 16 2 17 2 18 2 19 2 20 2 21 2 22 2 23 2 24 2 25 2 26 2 27 2 28 2 29 2 30 2 31 2 32 2 33 2 34 2 35 2 36 2 37 2 38 2 39 2 40 2 41 2 42 2 43 2 44 2 45 2 46 2 47 2 48 2 49 2 50 2
A=`expr $A + 1`
echo  $A
done

time ./xx.sh > /dev/null

·涉及相關的Redis源碼：void msetGenericCommand(redisClient *c, int nx) / t_string.c

·測試結果：

1，測試從M=50對KV（C=20000）開始，每50遞增，到700為止，到后面USR/SYS曲線接近擬合（甚至USR會超越SYS）、耗時平穩(wěn)后終止測試。

2，M值完全突破了之前的200傳聞，M帶的值越多FOR的性價比越高，隨之而來就是USR的上升，與SYS網(wǎng)絡開銷的減少。

·個人見解

1，本次測試重在重新審視MSET的性能，可以今后CPU使用率作為優(yōu)化切入，優(yōu)化批量數(shù)據(jù)插入，為今后程序設計和數(shù)據(jù)遷移提供參考依據(jù)。

2，Redis在真正處理批量數(shù)據(jù)時還是單線程的For，代碼執(zhí)行到For時會獨占CPU資源，但總比耗在TCP的閉合上有價值（盡管有EPOLL的打底），這也是一直提倡SET方式之一。

3，因為是For，setkey后再void notifyKeyspaceEvent(int type, char *event, robj *key, int dbid)，沒有rollback和批量類同commit，所以原著中"MSET是一個原子性(atomic)操作，所有給定key都會在同一時間內被設置，某些給定key被更新而另一些給定key沒有改變的情況，不可能發(fā)生。"這句話值得商榷。

3，如果Redis服務器的CPU還未用滿，不知道今后時候對For的處理是否會有進一步的優(yōu)化方向，大家有興趣可以改寫測試一下。

4，主從模式有everysync和always（集群方案有待研究）被很多人拿來吐槽，甚至拿來和MongoDB相比，個人見解，數(shù)據(jù)的重要性如果要是靠Redis來解決，這套程序的架構設計本質上也存在重大問題，更何況究竟有多人會真正碰到丟數(shù)據(jù)的情況。

總結

以上是生活随笔為你收集整理的Redis MSET的极限在哪里的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。