1
前言
1.1 社群數字場景
社群業務有非常多的數字統計場景，基礎的場景主要有以下這些：
- 使用者次元：釋出内容數、被點贊數、被收藏數、關注數、粉絲數、點贊内容數、收藏内容數等。
- 内容次元：内容點贊數、内容閱讀數、内容分享數、内容收藏數、内容評論數等。
- 标簽次元：話題内容數、特效内容數、商品内容數、品牌内容數等。
其中部分場景還會有很多細分情況，例如内容相關的統計還會有以下場景：
- 根據内容類型統計：圖文數、視訊數、專欄數等。
這樣排列組合出來的最終結果就有很多了，比如需要查詢使用者釋出的圖文内容數、使用者點贊的視訊内容數等等，且這些數字一般都需要能夠支援高度精确性、高性能查詢和批量查詢等能力。
1.2 具體案例
具體案例可參考下列圖示：
- 圖1. 個人首頁展示獲贊與收藏總數、粉絲數、關注數、釋出動态數(視訊數、穿搭精選數、專欄數)。
(圖1)
- 圖2. 他人首頁展示獲贊與收藏總數、粉絲數、關注數、點贊動态數(視訊數、專欄數)。
(圖2)
- 圖3. 話題首頁展示話題内容數。
(圖3)
2
逐漸浮現的系統風險
2.1 曆史方案
早期社群是直接采用Count資料表+緩存的方式，這種方式在體量較小和單體服務的情況下完全沒問題，而且成本低、性能高、絕對精準，但随着社群的體量逐漸變大、微服務拆分越來越細之後，該方案就會越來越難以支撐業務。
2.2 系統風險
- 性能瓶頸和穩定性風險：
- 一方面業務明細表的體量越來越大，需要通過分庫分表來解決問題，分庫分表後再用Count聚合的方式性能就會變差。
- 另一方面業務統計規則越來越複雜，使用資料庫Count的方式會使資料查詢語句越來越複雜，容易引發慢SQL進而導緻資料庫不穩定。
- 計數業務資料層和緩存都和核心業務部分放在一起，若出現統計導緻的不穩定會影響核心業務場景的使用，進而将小問題變成大問題。
- 緩存政策問題：
- 熱點穿透問題：部分計數場景下是有新資料就删除緩存的政策，但若出現熱點内容、熱點使用者時，對應的統計資料(如點贊數、粉絲數)會頻繁删除緩存導緻穿透的問題，且一般熱點内容和使用者産生的資料量比較大、查詢量也比較大，會更容易加劇問題進而引發雪崩。
- 資料一緻性問題：部分計數場景下是定時更新緩存的政策，緩存操作和MySQL操作無法在一個事務中完成，會産生不一緻的問題，且在越頻繁變更的場景下差異值就會越大。
3
計數系統設計與實作
結合目前社群的業務現狀、體量以及考慮中長期體量增長的規劃，我們也調研了業内比較常見的一些實作方案，最終敲定通過維護一套計數中心的服務，由計數中心服務統一管理社群的數字統計的方式，整體情況大緻如下：
3.1 寫場景
該場景下計數中心内部主要幹三件事，主要包括資料擷取、資料處理、資料持久化。
3.1.1 資料擷取
資料的擷取一般有兩種方式，通過接口或通過MQ的方式，既然是平台服務更希望對業務沒什麼侵入性，是以我們目前采用的主要是MQ的方式。
使用MQ的情況下也有兩種方案可取，一種是業務服務根據事件觸發MQ消息，需要業務服務先保證業務資料已經持久化且需要生産端保證消息投遞無丢失，另一種則是直接通過訂閱業務資料表binlog的方式，這種方式可以保證業務資料已經持久化，目前得物已有DTS(資料訂閱平台)，使用起來也比較友善且可保證消息投遞不丢失，是以我們目前更多的是采用第二種方案。
資料擷取到後我們做一些格基礎校驗，驗證是否存在我們必要的一些字段是否完整，同時需要驗證資料處理的幂等性防止資料重複消費等，通過消息ID和業務唯一ID做幂等，然後把每行業務資料的各字段格式化成變更前和變更後倆個值且可以區分出是新增還是更新(binlog消息體就是這樣是以更加友善)，之後就可以進入資料處理階段。
3.1.2 資料處理
拿到通過校驗和格式化後的資料，根據對應的事件和規則來判斷目前變更資料具體要做什麼操作，我們通過具體的案例來看會更直覺，如：
場景1. 使用者A關注使用者B
- 第一步，判斷出該場景下需要變更的統計數，使用者A的關注數要+1，使用者B的粉絲數要+1。
- 第二步，提取需要變更的統計數的對象值，如使用者A的ID和使用者B的ID。
- 第三步，格式化成統計的格式，對象ID+統計類型+統計數變化值。
- 第四步，調用資料持久化的方法。
場景2. 使用者A釋出的圖文内容狀态由正常變為删除
- 第一步，判斷出該場景下需要變更的統計數，使用者A釋出的圖文内容數要-1。
- 第二步，提取需要變更的統計數的對象值，如使用者A的ID。
- 第三步，格式化成統計的格式，對象ID+統計類型+統計數變化值。
- 第四步，調用資料持久化的方法。
3.1.3 資料持久化
持久化部分主要分為兩塊，一是DB持久化，二是對于緩存的更新。社群的數字統計場景主要有以下兩種情況：
- 隻增不減：如内容分享事件，每次事件觸發隻需要給内容的分享數+1即可。
- 既有增又有減：如使用者A(關注/取消關注)使用者B事件，需要給使用者A關注數(+1/-1)，也需要給使用者B的粉絲數(+1/-1)。
又因為我們通過MQ消費資料是無序的，極端情況下可能會出現先減再加的情況進而導緻負數的出現，是以存儲層的字段需要支援有符号的資料，保證最終計算的結果是正确的即可。DB層持久完成後再直接操作緩存變更數字并延長有效期，若緩存不存在則不處理等待讀場景有需要時再處理。
3.2 讀場景
讀場景整體邏輯比較簡潔，就是先查緩存，緩存不存在就查詢DB再寫入緩存即可，可批量跨場景查詢，需要注意對負數情況的處理。
4
總結及規劃
4.1 總結
計數中心是業内比較常見的做法，相對于老方案能夠降低各個業務對于複雜計數場景的維護成本，提升疊代效率和系統穩定性，獨立出來後在出現異常時業務也可做短時間降級，進而降低對核心業務的影響面。
4.2 規劃
目前社群已有多個場景接入計數中心，結合目前的現狀及未來的可能性，考慮後續主要優化方向主要有：
| 降低新增場景的接入成本和效率 | 計數中心服務的Owner更多的是維護系統層面的流程及穩定性，對于上遊的業務邏輯并不都是很了解，如果需要擴大業務場景，可以考慮将統計規則部分做到可配置，将業務的部分交給業務處理，其他流程編排部分通用化。 |
作者:小夏
來源:微信公衆号:得物技術
出處:https://mp.weixin.qq.com/s/bVZMwGMqMudWxkdkGK59LA