counter服务报警问题分析解决
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了counter服务报警问题分析解决相关的知识,希望对你有一定的参考价值。
counter服务介绍:
我们sae这边counter服务给用户提供的功能为计数器服务,使用的软件为redis。而我们对counter服务的监控,是通过monitor来做的,主要操作就是set,get,delete,increase,create,remove等操作。而counter报警问题,之前也存在,大概两三天会有一次报警。
报警问题主要分为如下两个阶段:
一,某天counter服务频繁报警:
是因为之前monitor的counter监控只监控了com组webruntime,
把ent,bigapp加进去之后,频繁报警。这是因为ent,bigapp组sae-php-saecounter软件包版本比较低,
而低版本的包代码中没有添加执行redis操作失败的重试机制。软件版本统一之后,每天counter的报警大概在十几条左右。
注:ent,bigapp组counter没升级的原因为新counter的软件包一直在com组做灰度
二,counter服务每天十几条的报警:
通过分析报警内容,redis的 aof文件,monitor报警逻辑及分析tcpdump抓的数据包发现一些问题,具体如下:
1,报警内容都是create和remove的时候没有成功,其它的set,get,increase操作没问题。
2,create和remove一个key的时候,是一个事物操作。但是,在aof文件中看涉及对两个key的操作。和服务负责人确认,是代码逻辑添加的。涉及到的一个key是hash表中客户端要操作的key本身,另一个key是记录此hash表的key数量(ent或com或
bigapp组每组的counter的monitor会共用一个key)
3,在抓包中看到,报警的ent webruntime机器在执行一个remove key事物操作前,已经被redis
watch的key(这个key为此hash表的key数量,watch操作也是在代码中的)被另一台ent
webruntime给修改了(因为monitor报警是并发的,故对redis的操作在一段时间内,不一定只有一台机器执行),导致remove或者
create的时候,redis发现被watch的key修改了,故停止执行此事物操作,重试5次没有成功,故导致monitor报警
解决办法:
1,适当增大redis命令执行失败后的delay时间和重试次数,这样当事务执行失败后,会在延迟后继续重试执行,一定程度降低失败率
2,修改counter代码逻辑,可以通过hlen命令获得hash表的长度。可以解决这个问题
最终我们才用第二种方法解决了这个问题。
本文出自 “佳” 博客,请务必保留此出处http://leejia.blog.51cto.com/4356849/1758172
以上是关于counter服务报警问题分析解决的主要内容,如果未能解决你的问题,请参考以下文章