建站
咨詢
售后
建站咨詢
新聞中心
應(yīng)用場景
說起計數(shù)器，大多數(shù)人都不陌生，畢竟計數(shù)器的應(yīng)該實(shí)在是太多太多了。小到一個博客系統(tǒng)的文章數(shù)目，大到抖音視頻點(diǎn)贊數(shù)、評論數(shù)，淘寶中商品庫存數(shù)量等等。
創(chuàng)新互聯(lián)公司主營丁青網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營網(wǎng)站建設(shè)方案,APP應(yīng)用開發(fā),丁青h5微信小程序開發(fā)搭建,丁青網(wǎng)站營銷推廣歡迎丁青等地區(qū)企業(yè)咨詢
可以說計數(shù)的目的就是為一個對象打上一個數(shù)字，這個數(shù)字用于表征某種業(yè)務(wù)含義。通常情況下，我們不一定需要顯示地去創(chuàng)建一個計數(shù)器，比如我們要統(tǒng)計店鋪的寶貝數(shù)量，只要寫一個 SQL 語句把剩余的商品數(shù)量實(shí)時統(tǒng)計出來，這樣實(shí)現(xiàn)的精確度最高，但是缺陷就是如果流水?dāng)?shù)量很大，會出現(xiàn)明顯的性能瓶頸。比如說，我們以抖音的點(diǎn)贊數(shù)為例，對于一個火熱的視頻，有百萬級的點(diǎn)贊流水，顯然每次都有count如此大的數(shù)量是不可能的。
所以，這個時候計數(shù)器的需求就橫空出世了，計數(shù)器，簡單理解就是幫助我們快速獲取 count 結(jié)果的機(jī)制。
計數(shù)器使用案例：高性能獲取計數(shù)值
分布式計數(shù)器的實(shí)現(xiàn)
單機(jī)計數(shù)器的實(shí)現(xiàn)沒什么好說的，每種編程語言都提供了對應(yīng)的數(shù)據(jù)結(jié)構(gòu)，這里我們來分析下分布式計數(shù)器的實(shí)現(xiàn)方法。通常，我們有兩種選擇：MySQL 計數(shù)器、Redis 計數(shù)器。
① 基于 MySQL 實(shí)現(xiàn)計數(shù)器
使用 MySQL 來實(shí)現(xiàn)計數(shù)器，我們可以單獨(dú)創(chuàng)建一張表，這個表主要有一個業(yè)務(wù)主鍵列，用于表示業(yè)務(wù)id(比如視頻id)，同時需要有個計數(shù)列，用于記錄當(dāng)前的計數(shù)值。
一張簡單的 MySQL 表
當(dāng)有數(shù)據(jù)增加時，可以使用樂觀鎖保證冪等性，如果執(zhí)行失敗自旋重試即可。
// 先 select 出當(dāng)前 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 實(shí)現(xiàn)計數(shù)器很簡單，而且如果業(yè)務(wù)數(shù)據(jù)也在 MySQL 中，那么可以很方便地做跨表事務(wù)，保證整體數(shù)據(jù)的一致性。但是缺陷也很明顯，因?yàn)?`update` 語句存在行鎖(甚至如果id不是主鍵，可能是間隙鎖)，那么在競爭激烈的情況下，可能存在嚴(yán)重的性能退化。
這個時候，可以考慮做一下性能優(yōu)化：減小鎖粒度。
實(shí)現(xiàn)也很簡單，就是相同業(yè)務(wù) ID 可以用 X 條數(shù)據(jù)，每次更新的時候隨機(jī)更新一條，這樣鎖沖突的概率就降低到 1 / X 了，查詢計數(shù)值的時候需要修改為對相同業(yè)務(wù) ID 求 Sum(count)。
② 基于 Redis 實(shí)現(xiàn)計數(shù)器
使用 Redis 來作為分布式計數(shù)器也是一種常見的手段，相比于 MySQL，Redis 幾乎不存在性能問題(單機(jī)可支持10w qps+)，并且 Redis 內(nèi)置了 `IncrBy` 操作，可以原子的實(shí)現(xiàn)計數(shù)的累加。
但是，使用 Redis 作為計數(shù)器有個困擾之一就是操作是非冪等的，比如你調(diào)用了 `IncrBy` 命令后，收到網(wǎng)絡(luò)錯誤，你無法確定服務(wù)端到底是執(zhí)行成功了，還是執(zhí)行失敗了。這導(dǎo)致你無法確定是否應(yīng)該重試，最終導(dǎo)致計數(shù)結(jié)果的偏差，典型的兩軍問題。
為了解決這個問題，最常見的方法是使用 LUA 腳本，在每次要執(zhí)行 INCR 的時候，同時使用 `SETNX` 設(shè)置一個值，LUA 腳本保證 SETNX 和 INCR 操作同時成功或者同時失敗(原子性)，這樣當(dāng)你收到錯誤的返回信息時，是否要重試僅是判斷對應(yīng)的 KEY 是否已經(jīng)設(shè)置成功了。
舉個栗子：某個視頻收到一個點(diǎn)贊，假設(shè)點(diǎn)贊的業(yè)務(wù)id=1000，那么 LUA 腳本的執(zhí)行邏輯是 `SETNX 1000 true` + `IncrBy countKey` 同時成功。
最后，使用 Redis 計數(shù)器，要防止熱 KEY。雖然 Redis 能承受的請求量很大， 但是畢竟是單點(diǎn)存儲(讀寫分離)，所有寫請求還是都打在同個節(jié)點(diǎn)上，需要評估對單個節(jié)點(diǎn)的寫入 QPS，務(wù)必防止超熱的 KEY 出現(xiàn)。
權(quán)衡：一致性與可用性
通常情況下，計數(shù)器和流水單獨(dú)計算，由于是異構(gòu)存儲，可能存在一定的不一致性。
這個時候，我們需要權(quán)衡業(yè)務(wù)對不一致性的容忍情況，一般需要權(quán)衡的是可用性以及一致性的沖突。
如果一致性很重要，可以考慮使用 MySQL 模式，將業(yè)務(wù)數(shù)據(jù)與計數(shù)器做在同個事務(wù)中，保證強(qiáng)一致，或者引入分布式事務(wù)，來保證異構(gòu)存儲的一致性，或者是使用 Redis 計數(shù)器 + LUA 腳本模式等。
但是，需要注意的是無論是何種模式，一致性高的，必然性能、可用性會有所折損。如果業(yè)務(wù)沒有強(qiáng)訴求，無需搞得這么復(fù)雜，可以引入一個定時回掃腳本，定時更正下即可。
記住，不考慮業(yè)務(wù)的架構(gòu)，都是耍流氓。
結(jié)束語
在我們的業(yè)務(wù)開發(fā)工作中，經(jīng)常會遇到計數(shù)器的訴求。剛開始，我覺得很簡單，不就是 Redis Incr 一下嗎?實(shí)際上，當(dāng)業(yè)務(wù)變得復(fù)雜，當(dāng)數(shù)據(jù)量變得龐大，當(dāng)對計數(shù)器的一致性要求變高，這一切在演進(jìn)中都變得復(fù)雜而難以處理。
上面的是我在日常工作中總結(jié)的兩種比較常用且有效的分布式計數(shù)器實(shí)現(xiàn)方案，如果你的工作中也有用到，也可以嘗試嘗試。如果暫時沒有用到，適當(dāng)?shù)牧私?，在面試、日常的工作交流中相信也都會受用?/p>
當(dāng)前題目：系統(tǒng)設(shè)計之分布式計數(shù)器
文章出自：http://www.dlmjj.cn/article/djioccj.html
