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