Redis MSET的極限在哪裏

·背景

    Redis以"快、準、狠"而著稱，除了其主-從模式略失光彩（主從模式更可能是被以訛傳訛，3.0依舊在測試中），大部分的應用可謂尖兵利器。在一些常規寫的時候，MSET和HMSET也是被你們最推崇的模式之一，以前網上有篇文章說到M的極限在200之後會趨於飽和，那麼到底是不是這樣，今天無聊作了下測試。

 

·測試場景

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

·數量：測試K-V量100萬條 ，變量爲M和C。M爲一次帶上的K-V條數，C爲輪訓次數（類同網絡開閉成本），二者乘積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）、耗時平穩後終止測試。

2，M值徹底突破了以前的200傳聞，M帶的值越多FOR的性價比越高，隨之而來就是USR的上升，與SYS網絡開銷的減小。

·我的看法

1，本次測試重在從新審視MSET的性能，能夠從此CPU使用率做爲優化切入，優化批量數據插入，爲從此程序設計和數據遷移提供參考依據。

2，Redis在真正處理批量數據時仍是單線程的For，代碼執行到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 沒有改變的狀況，不可能發生。"這句話值得商榷。

3，若是Redis服務器的CPU還未用滿，不知道從此時候對For的處理是否會有進一步的優化方向，你們有興趣能夠改寫測試一下。

4，主從模式有everysync和always（集羣方案有待研究）被不少人拿來吐槽，甚至拿來和MongoDB相比，我的看法，數據的重要性若是要是靠Redis來解決，這套程序的架構設計本質上也存在重大問題，更況且究竟有多人會真正碰到丟數據的狀況。