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本身,数据结构:appname -> {"count_1":num,"count_2":num},即keyname为这个应用的appname,hash表中的value为这个应用创建的所有计数器,限制为每个应用最多100个计数器;另一个key是记录此hash表的key数量,数据结构:appname_len -> num,即keyname为这个应用appname加字符串"_len",value为hash表的长度,由于com组monitor是com组的一个应用,ent和bigapp组的monitor同理也是一个应用,所以,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表的长度。可以解决这个问题


最终我们才用第二种方法解决了这个问题。