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表的长度。可以解决这个问题
最终我们才用第二种方法解决了这个问题。
