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