storm写redis问题小结

  最近一直在跟进storm的问题，从storm集群的稳定性到监控到升级到bolt写redis的问题,由于公司目前没有专业运维redis的，只能咱们数据部门本身搞了。。下面记录下遇到的几个问题:

总结下目前storm写redis问题:

1.redis高峰写入异常，增长redis监控，发现cpu性能瓶颈(redis单线程，最高10w/s的处理量)

2.以前redis bolt的并发在200以上，过多的并发对redis的性能形成比较大的影响，如今已经减小为5

3.关闭了redis的monitor监控,常驻的monitor监控对redis的性能损耗在30%左右

4.关闭了redis的rdb持久化方式，开启了aof的方式，在低峰aofrewrite

5.扩容到8个实例，使用jedissharding的方式，高峰时单机超过5W/s处理量

6.去掉select操做，使用默认db0

7.对高峰时的数据进行分析，40w/s的处理量中，ping操做占50%以上，调整jedispool的设置，基本上屏蔽了ping的操做

8.bolt端batch处理，减小写入量

9.40%的expire操做，测试ttl+expire vs expire的性能，基于ttl+expire的方式在一个操做里面的性能损耗在35%左右，

若是是同一个key在一个线程里面顺序操做会有性能的提高（目前咱们没有这种场景）

1)直接expire

hardedJedis.set(key,value)

hardedJedis.expire(key,1000)

2)ttl+expire

hardedJedis.set(key,value)

Long re = shardedJedis.ttl(key);

if ((re == -1)||(re == -2)){hardedJedis.expire(key,1000)};

10.从第8点测试来看40%的expire操做是省不了了，只能从提升单次处理量(pipline)来作优化了

11.测试了lvs->twemproxy->redis的方案，不太稳定，考虑引用到的组件比较多，twemproxy相对来讲对于咱们这边也是一个黑盒

12.jedissharding的方案在高峰时会有一些延迟，单机方案相对来讲比较稳定，若是接入数据量变大的话仍是要走sharding模式，延迟的缘由须要继续跟进

最后附几个监控图：

1.redis cpu

2.redis conns

3.redis command/s