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来解决，这套程序的架构设计本质上也存在重大问题，更况且究竟有多人会真正碰到丢数据的状况。