繼續(xù)答星球水友提問(wèn)，30WQPS的點(diǎn)贊計(jì)數(shù)業(yè)務(wù)，如何設(shè)計(jì)?

可以看到，這個(gè)業(yè)務(wù)的特點(diǎn)是：

• 吞吐量超高;
• 能夠接受一定數(shù)據(jù)不一致;

畫外音：計(jì)數(shù)有微小不準(zhǔn)確，不是大問(wèn)題。

先用最樸素的思想，只考慮點(diǎn)贊計(jì)數(shù)，可以怎么做?有幾點(diǎn)是最容易想到的：

• 肯定不能用數(shù)據(jù)庫(kù)抗實(shí)時(shí)讀寫流量;
• redis天然支持固化，可以用高可用redis集群來(lái)做固化存儲(chǔ);
• 也可以用MySQL來(lái)做固化存儲(chǔ)，redis做緩存，讀寫操作都落緩存，異步線程定期刷DB;
• 架一層計(jì)數(shù)服務(wù)，將計(jì)數(shù)與業(yè)務(wù)邏輯解耦;

此時(shí)MySQL核心數(shù)據(jù)結(jié)構(gòu)是：

t_count(msg_id, praise_count) 

此時(shí)redis的KV設(shè)計(jì)也不難：

• key：msg_id
• value：praise_count

似乎很容易就搞定了：

• 服務(wù)可以水平擴(kuò)展;
• 數(shù)據(jù)量增加時(shí)，數(shù)據(jù)庫(kù)可以水平擴(kuò)展;
• 讀寫量增加時(shí)，緩存也可以水平擴(kuò)展;

計(jì)數(shù)系統(tǒng)的難點(diǎn)，還在于業(yè)務(wù)擴(kuò)展性問(wèn)題，以及效率問(wèn)題。

以微博為例：

• 用戶微博首頁(yè)，有多條消息list，這是一種擴(kuò)展;
• 同一條消息msg_id，不止有點(diǎn)贊計(jì)數(shù)，還有閱讀計(jì)數(shù)，轉(zhuǎn)發(fā)計(jì)數(shù)，評(píng)論計(jì)數(shù)，這也是一種擴(kuò)展;

假如用最樸素的方式實(shí)現(xiàn)，多條消息多個(gè)計(jì)數(shù)的獲取偽代碼如下：

// (1)獲取首頁(yè)所有消息msg_id 
list<msg_id> = getHomePageMsg(uid); 
// (2)對(duì)于首頁(yè)的所有消息要拉取多個(gè)計(jì)數(shù) 
for( msg_id in list<msg_id>){ 
         //(3.1)獲取閱讀計(jì)數(shù) 
         getReadCount(msg_id);  
         //(3.2)獲取轉(zhuǎn)發(fā)計(jì)數(shù) 
         getForwordCount(msg_id); 
         //(3.3)獲取評(píng)論計(jì)數(shù) 
         getCommentCount(msg_id); 
         //(3.4)獲取贊計(jì)數(shù) 
         getPraiseCount(msg_id); 
} 

由于同一個(gè)msg_id多了幾種業(yè)務(wù)計(jì)數(shù)，redis的key需要帶上業(yè)務(wù)flag，升級(jí)為：

msg_id:read 
msg_id:forword 
msg_id:comment 
msg_id:praise 

用來(lái)區(qū)分共一個(gè)msg_id的四種不同業(yè)務(wù)計(jì)數(shù)，redis不能支持key的模糊操作，必須訪問(wèn)四次reids。

假設(shè)首頁(yè)有100條消息，這個(gè)方案總結(jié)為：

• for循環(huán)每一條消息，100條消息100次;
• 每條消息4次RPC獲取計(jì)數(shù)接口調(diào)用;
• 每次調(diào)用服務(wù)要訪問(wèn)reids，拼裝key獲取count;

畫外音：這種方案的擴(kuò)展性和效率是非常低的。

那如何進(jìn)行優(yōu)化呢?

首先看下數(shù)據(jù)庫(kù)層面元數(shù)據(jù)擴(kuò)展，常見(jiàn)的擴(kuò)展方式是，增加列，記錄更多的業(yè)務(wù)計(jì)數(shù)。

如上圖所示，由一列點(diǎn)贊計(jì)數(shù)，擴(kuò)充為四列閱讀、轉(zhuǎn)發(fā)、評(píng)論、點(diǎn)贊計(jì)數(shù)。

增加列這種業(yè)務(wù)計(jì)數(shù)擴(kuò)展方式的缺點(diǎn)是：每次要擴(kuò)充業(yè)務(wù)計(jì)數(shù)時(shí)，總是需要修改表結(jié)構(gòu)，增加列，很煩。

有沒(méi)有不需要變更表結(jié)構(gòu)的擴(kuò)展方式呢?

行擴(kuò)展是一種擴(kuò)展性更好的方式。

表結(jié)構(gòu)固化為：

t_count(msg_id, count_key, count_value) 

當(dāng)要擴(kuò)充業(yè)務(wù)計(jì)數(shù)時(shí)，增加一行就行，不需要修改表結(jié)構(gòu)。

畫外音：很多配置業(yè)務(wù)，會(huì)使用這種方案，方便增加配置。

增加行這種業(yè)務(wù)計(jì)數(shù)擴(kuò)展方式的缺點(diǎn)是：表數(shù)據(jù)行數(shù)會(huì)增加，但這不是主要矛盾，數(shù)據(jù)庫(kù)水平擴(kuò)展能很輕松解決數(shù)據(jù)量大的問(wèn)題。

接下來(lái)看下redis批量獲取計(jì)數(shù)的優(yōu)化方案。

原始方案，通過(guò)拼裝key來(lái)區(qū)分同一個(gè)msg_id的不同業(yè)務(wù)計(jì)數(shù)。

可以升級(jí)為，同一個(gè)value來(lái)存儲(chǔ)多個(gè)計(jì)數(shù)。

如上圖所示，同一個(gè)msg_id的四個(gè)計(jì)數(shù)，存儲(chǔ)在一個(gè)value里，從而避免多次redis訪問(wèn)。

畫外音：通過(guò)value來(lái)擴(kuò)展，是不是很巧妙?

總結(jié)

計(jì)數(shù)業(yè)務(wù)，在數(shù)據(jù)量大，并發(fā)量大的時(shí)候，要考慮的一些技術(shù)點(diǎn)：

• 用緩存抗讀寫;
• 服務(wù)化，計(jì)數(shù)系統(tǒng)與業(yè)務(wù)系統(tǒng)解耦;
• 水平切分?jǐn)U展吞吐量、數(shù)據(jù)量、讀寫量;
• 要考慮擴(kuò)展性，數(shù)據(jù)庫(kù)層面常見(jiàn)的優(yōu)化有：列擴(kuò)展，行擴(kuò)展兩種方式;
• 要考慮批量操作，緩存層面常見(jiàn)的優(yōu)化有：一個(gè)value存儲(chǔ)多個(gè)業(yè)務(wù)計(jì)數(shù);

計(jì)數(shù)系統(tǒng)優(yōu)化先聊到這里，希望大家有收獲。

【本文為51CTO專欄作者“58沈劍”原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】

戳這里，看該作者更多好文