應用場景

說起計數(shù)器，大多數(shù)人都不陌生，畢竟計數(shù)器的應該實在是太多太多了。小到一個博客系統(tǒng)的文章數(shù)目，大到抖音視頻點贊數(shù)、評論數(shù)，淘寶中商品庫存數(shù)量等等。

可以說計數(shù)的目的就是為一個對象打上一個數(shù)字，這個數(shù)字用于表征某種業(yè)務含義。通常情況下，我們不一定需要顯示地去創(chuàng)建一個計數(shù)器，比如我們要統(tǒng)計店鋪的寶貝數(shù)量，只要寫一個 SQL 語句把剩余的商品數(shù)量實時統(tǒng)計出來，這樣實現(xiàn)的精確度最高，但是缺陷就是如果流水數(shù)量很大，會出現(xiàn)明顯的性能瓶頸。比如說，我們以抖音的點贊數(shù)為例，對于一個火熱的視頻，有百萬級的點贊流水，顯然每次都有count如此大的數(shù)量是不可能的。

所以，這個時候計數(shù)器的需求就橫空出世了，計數(shù)器，簡單理解就是幫助我們快速獲取 count 結果的機制。

計數(shù)器使用案例：高性能獲取計數(shù)值

分布式計數(shù)器的實現(xiàn)

單機計數(shù)器的實現(xiàn)沒什么好說的，每種編程語言都提供了對應的數(shù)據(jù)結構，這里我們來分析下分布式計數(shù)器的實現(xiàn)方法。通常，我們有兩種選擇：MySQL 計數(shù)器、Redis 計數(shù)器。

① 基于 MySQL 實現(xiàn)計數(shù)器

使用 MySQL 來實現(xiàn)計數(shù)器，我們可以單獨創(chuàng)建一張表，這個表主要有一個業(yè)務主鍵列，用于表示業(yè)務id(比如視頻id)，同時需要有個計數(shù)列，用于記錄當前的計數(shù)值。

一張簡單的 MySQL 表

當有數(shù)據(jù)增加時，可以使用樂觀鎖保證冪等性，如果執(zhí)行失敗自旋重試即可。

// 先 select 出當前 current_count
select count as current_count from xxx where id = 'xxx'
// 更新計數(shù)值
update xxx set count = current_count + 1 where id = 'xxx' and count = current_count

用 MySQL 實現(xiàn)計數(shù)器很簡單，而且如果業(yè)務數(shù)據(jù)也在 MySQL 中，那么可以很方便地做跨表事務，保證整體數(shù)據(jù)的一致性。但是缺陷也很明顯，因為 `update` 語句存在行鎖(甚至如果id不是主鍵，可能是間隙鎖)，那么在競爭激烈的情況下，可能存在嚴重的性能退化。

這個時候，可以考慮做一下性能優(yōu)化：減小鎖粒度。

實現(xiàn)也很簡單，就是相同業(yè)務 ID 可以用 X 條數(shù)據(jù)，每次更新的時候隨機更新一條，這樣鎖沖突的概率就降低到 1 / X 了，查詢計數(shù)值的時候需要修改為對相同業(yè)務 ID 求 Sum(count)。

② 基于 Redis 實現(xiàn)計數(shù)器

使用 Redis 來作為分布式計數(shù)器也是一種常見的手段，相比于 MySQL，Redis 幾乎不存在性能問題(單機可支持10w qps+)，并且 Redis 內置了 `IncrBy` 操作，可以原子的實現(xiàn)計數(shù)的累加。

但是，使用 Redis 作為計數(shù)器有個困擾之一就是操作是非冪等的，比如你調用了 `IncrBy` 命令后，收到網(wǎng)絡錯誤，你無法確定服務端到底是執(zhí)行成功了，還是執(zhí)行失敗了。這導致你無法確定是否應該重試，最終導致計數(shù)結果的偏差，典型的兩軍問題。

為了解決這個問題，最常見的方法是使用 LUA 腳本，在每次要執(zhí)行 INCR 的時候，同時使用 `SETNX` 設置一個值，LUA 腳本保證 SETNX 和 INCR 操作同時成功或者同時失敗(原子性)，這樣當你收到錯誤的返回信息時，是否要重試僅是判斷對應的 KEY 是否已經設置成功了。

舉個栗子：某個視頻收到一個點贊，假設點贊的業(yè)務id=1000，那么 LUA 腳本的執(zhí)行邏輯是 `SETNX 1000 true` + `IncrBy countKey` 同時成功。

最后，使用 Redis 計數(shù)器，要防止熱 KEY。雖然 Redis 能承受的請求量很大， 但是畢竟是單點存儲(讀寫分離)，所有寫請求還是都打在同個節(jié)點上，需要評估對單個節(jié)點的寫入 QPS，務必防止超熱的 KEY 出現(xiàn)。

權衡：一致性與可用性

通常情況下，計數(shù)器和流水單獨計算，由于是異構存儲，可能存在一定的不一致性。

這個時候，我們需要權衡業(yè)務對不一致性的容忍情況，一般需要權衡的是可用性以及一致性的沖突。

如果一致性很重要，可以考慮使用 MySQL 模式，將業(yè)務數(shù)據(jù)與計數(shù)器做在同個事務中，保證強一致，或者引入分布式事務，來保證異構存儲的一致性，或者是使用 Redis 計數(shù)器 + LUA 腳本模式等。

但是，需要注意的是無論是何種模式，一致性高的，必然性能、可用性會有所折損。如果業(yè)務沒有強訴求，無需搞得這么復雜，可以引入一個定時回掃腳本，定時更正下即可。

記住，不考慮業(yè)務的架構，都是耍流氓。

結束語

在我們的業(yè)務開發(fā)工作中，經常會遇到計數(shù)器的訴求。剛開始，我覺得很簡單，不就是 Redis Incr 一下嗎?實際上，當業(yè)務變得復雜，當數(shù)據(jù)量變得龐大，當對計數(shù)器的一致性要求變高，這一切在演進中都變得復雜而難以處理。

上面的是我在日常工作中總結的兩種比較常用且有效的分布式計數(shù)器實現(xiàn)方案，如果你的工作中也有用到，也可以嘗試嘗試。如果暫時沒有用到，適當?shù)牧私?，在面試、日常的工作交流中相信也都會受用?/p>