寫在最前面
今天下定決心說不寫其他的文章了建丧，但是還是沒忍住腿堤，想把現(xiàn)在接觸到的東西都趕快的記錄下來阀坏，防止以后忘記。還有可能就是越得不到的東西越珍惜吧笆檀，所以想趕快把他記下來忌堂，把想法記下來。以后可能有一天我有能力或者有決定權的時候或許可以用上~
計數(shù)服務
計數(shù)服務酗洒，簡單來說就是一個打點服務士修，看似很簡單，不就是進行一個數(shù)據(jù)的累加嗎樱衷，有什么的棋嘲？但是可真的不是這樣的。計數(shù)可以幫助我們干很多很多事情箫老。例如服務的異常數(shù)封字，服務的調(diào)用次數(shù)，哪些接口的調(diào)用次數(shù)耍鬓，等等等阔籽。
計數(shù)服務可以做什么
我們都知道時間序列這個詞，這個詞代表每個時間點上的數(shù)據(jù)數(shù)量的集合牲蜀。我們有了計數(shù)服務其實我們就得到了某個指標的對應時間序列笆制。有了時間序列以后我們就可以知道很多信息，例如系統(tǒng)是否有高峰點涣达，例如系統(tǒng)哪些時間發(fā)生的異常比較多在辆。例如哪些業(yè)務邏輯走的比較多等等证薇。
最終要的，有了時間序列我們甚至可以對數(shù)據(jù)進行預測匆篓，對數(shù)據(jù)進行異常檢測浑度。
這么一說，是不是覺得計數(shù)服務就是很有必要的了呢鸦概？
現(xiàn)有的計數(shù)服務
目前其實也有計數(shù)服務箩张，例如美團點評的CAT窗市，這里給CAT打個小廣告吧论熙，真心覺得這個產(chǎn)品做得非常棒！
但是CAT也會有一定的瓶頸摄狱，例如CAT的數(shù)據(jù)延遲比較高脓诡，我們上報一個數(shù)據(jù)以后可能很長時間才能看到真正的數(shù)據(jù)。還有就是CAT的數(shù)據(jù)存儲方面了二蓝，不支持太多的持久化數(shù)據(jù)存儲誉券。
所以基于以上幾點，自己做一個計數(shù)服務勢在必行了刊愚。
計數(shù)服務的架構圖
關于計數(shù)服務踊跟，主要是依賴于客戶端的匯聚操作和遠程的通訊操作，數(shù)據(jù)存儲在遠程鸥诽，遠程的Redis或者其他的計數(shù)器作為全局計數(shù)器牡借，這個全局計數(shù)器的集群需要高可用拳昌，可以用集群自帶的高可用操作。
主要有以下幾個核心點組成：
- 負責客戶端邏輯钠龙，也就是本地進程內(nèi)進行數(shù)據(jù)匯總的client客戶端炬藤。客戶端內(nèi)要有幾個關鍵點咬腋，一個是
countBuffer負責匯總一段時間內(nèi)的請求數(shù)量羹膳，與遠程交互的RedisClient，異步進行上報的ReportThread根竿。還有就是負責異常處理的ErrorHandleThread陵像。當然如果是同步累加的話每次與Redis進行交互就可以了就珠。 - Redis集群，負責核心的全局計數(shù)器操作醒颖，這個全局計數(shù)器主要靈感來源于限流算法妻怎，限流算法有幾種
令牌桶，漏桶图贸，全局計數(shù)器蹂季，這個地方就利用了全局計數(shù)器的這個概念。值得注意的是key的設計疏日，每分鐘或者每秒設置對應的key，從而區(qū)分每個計數(shù)的粒度撒汉。這個地方需要注意熱點key的出現(xiàn)（不過因為是間隔時間還可以所以基本上不會太出現(xiàn)） - Shower這個名字真心是拍腦袋想出來的沟优，其實就是一個數(shù)據(jù)展示，建議數(shù)據(jù)展示還是直接操作從的Redis把睬辐，定時同步出來一個挠阁，防止讀寫同時發(fā)生時候性能降低，也防止把主的查掛了溯饵。主要提供一個數(shù)據(jù)展示的視圖侵俗，或者提供一個數(shù)據(jù)查詢的API.
多說一點
這個其實是依賴于遠程的Redis做的計數(shù)，其實如果是實時性比較強的丰刊，感覺可以參考Hystrix的dashboard的做法隘谣，把數(shù)據(jù)直接存儲在客戶端里面，每次查詢的時候訪問每個客戶端啄巧，實時匯總數(shù)據(jù)寻歧。這樣的到的數(shù)據(jù)更加實時擂错，而且可以區(qū)分上報的機器信息儡循。
感覺自己真的是很奇怪，可能因為是天秤座裳扯，天生不是很喜歡被束縛
