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表的長度。可以解決這個問題
最終我們才用第二種方法解決了這個問題。