从品牌网站建设到网络营销策划,从策略到执行的一站式服务
最近一直在跟进storm的问题,从storm集群的稳定性到监控到升级到bolt写redis的问题,因为公司目前没有专业运维redis的,只能我们数据部门自己搞了。。下面记录下遇到的几个问题:
目前创新互联公司已为1000多家的企业提供了网站建设、域名、网站空间、网站托管、企业网站设计、清丰网站维护等服务,公司将坚持客户导向、应用为本的策略,正道将秉承"和谐、参与、激情"的文化,与客户和合作伙伴齐心协力一起成长,共同发展。
总结下目前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
成都网站建设公司地址:成都市青羊区太升南路288号锦天国际A座10层 建设咨询028-86922220
成都快上网科技有限公司-四川网站建设设计公司 | 蜀ICP备19037934号 Copyright 2020,ALL Rights Reserved cdkjz.cn | 成都网站建设 | © Copyright 2020版权所有.
专家团队为您提供成都网站建设,成都网站设计,成都品牌网站设计,成都营销型网站制作等服务,成都建网站就找快上网! | 成都网站建设哪家好? | 网站建设地图