,最近一直在跟进风暴的问题,从风暴集群的稳定性到监控到升级到螺栓写复述的问题,因为公司目前没有专业运维复述的,只能我们数据部门自己搞了. .下面记录下遇到的几个问题:
总结下目前风暴写复述,问题:
1.复述,高峰写入异常,增加复述,监控,发现cpu性能瓶颈(复述,单线程,最高10 w/s的处理量)
2。之前复述,螺栓的并发在200年以上,过多的并发对复述的性能造成比较大的影响,现在已经减少为5
3。关闭了复述的监视器监控,常驻的监视器监控对复述的性能损耗在30%左右
4。关闭了复述的rdb持久化方式,开启了aof的方式,在低峰aofrewrite
5。扩容到8个实例,使用jedissharding的方式,高峰时单机超过5 w/s处理量
6。去掉选择操作,使用默认db0
7。对高峰时的数据进行分析,40 w/s的处理量中,ping操作占50%以上,调整jedispool的设置,基本上屏蔽了萍的操作
8.螺栓端批处理,减少写入量
9.40%的到期操作,测试ttl +过期和失效的性能,基于ttl +到期的方式在一个操作里面的性能损耗在35%左右,
如果是同一个关键在一个线程里面顺序操作会有性能的提升(目前我们没有这种场景)
1)直接到期
hardedJedis.set(键值)
hardedJedis.expire(钥匙,1000)
2) ttl +
hardedJedis.set到期(键值)
长re=shardedJedis.ttl(关键);
如果((re==1) | | (re==2)) {hardedJedis.expire(关键,1000)};
10。从第8点测试来看40%的到期操作是省不了的了,只能从提高单次处理量(油)来做优化了
11。测试了lv→twemproxy→复述的方案,不太稳定,考虑引用到的组件比较多,twemproxy相对来说对于我们这边也是一个黑盒
12. jedissharding的方案在高峰时会有一些延迟,单机方案相对来说比较稳定,如果接入数据量变大的话还是要走分片模式,延迟的原因需要继续跟进
最后附几个监控图:
1。复述,cpu
2。复述,康涅狄格州
3。复述,命令/s
