【轉】計數系統架構實踐一次搞定

1、需求緣起

不少業務都有「計數」需求，以微博爲例：

微博首頁的我的中心部分，有三個重要的計數：

• 關注了多少人的計數

• 粉絲的計數

• 發佈博文的計數

微博首頁的博文消息主體部分，也有有不少計數，分別是一條博文的：

• 轉發計數

• 評論計數

• 點贊計數

• 甚至是瀏覽計數

 

在業務複雜，計數擴展頻繁，數據量大，併發量大的狀況下，計數系統的架構演進與實踐，是本文將要討論的問題。

 

2、業務分析與計數初步實現

典型的互聯網架構，經常分爲這麼幾層：

• 調用層：處於端上的browser或者APP

• 站點層：拼裝html或者json返回的web-server層

• 服務層：提供RPC調用接口的service層

• 數據層：提供固化數據存儲的db，以及加速存儲的cache

 

針對「緣起」裏微博計數的例子，主要涉及「關注」業務，「粉絲」業務，「微博消息」業務，通常來講，會有相應的db存儲相關數據，相應的service提供相關業務的RPC接口：

• 關注服務：提供關注數據的增刪查改RPC接口

• 粉絲服務：提供粉絲數據的增刪查改RPC接口

• 消息服務：提供微博消息數據的增刪查改RPC接口，消息業務相對比較複雜，涉及微博消息、轉發、評論、點贊等數據的存儲

 

對關注、粉絲、微博業務進行了初步解析，那首頁的計數需求應該如何知足呢？

很容易想到，關注服務+粉絲服務+消息服務均提供相應接口，就能拿到相關計數數據。

例如，我的中心首頁，須要展示博文數量這個計數，web層訪問message-service的count接口，這個接口執行：

select count(*) from t_msg where uid = XXX

同理，也很容易拿到關注，粉絲的這些計數。

 

這個方案叫作「count」計數法，在數據量併發量不大的狀況下，最容易想到且最常用的就是這種方法，但隨着數據量的上升，併發量的上升，這個方法的弊端將逐步展示。

 

例如，微博首頁有不少條微博消息，每條消息有若干計數，此時計數的拉取就成了一個龐大的工程：

整個拉取計數的僞代碼以下：

list<msg_id> = getHomePageMsg(uid);// 獲取首頁全部消息

for( msg_id in list<msg_id>){ // 對每一條消息

         getReadCount(msg_id);  // 閱讀計數

         getForwordCount(msg_id); // 轉發計數

         getCommentCount(msg_id); // 評論計數

         getPraiseCount(msg_id); // 贊計數

}

其中：

• 每個微博消息的若干個計數，都對應4個後端服務訪問

• 每個訪問，對應一條count的數據庫訪問（count要了老命了）

其效率之低，資源消耗之大，處理時間之長，可想而知。

 

「count」計數法方案，能夠總結爲：

• 多條消息屢次查詢，for循環進行

• 一條消息屢次查詢，多個計數的查詢

• 一次查詢一個count，每一個計數都是一個count語句

 

那如何進行優化呢？

 

3、計數外置的架構設計

計數是一個通用的需求，有沒有可能，這個計數的需求實如今一個通用的系統裏，而不是由關注服務、粉絲服務、微博服務來分別來提供相應的功能呢（不然擴展性極差）？

這樣須要實現一個通用的計數服務。

 

經過分析，上述微博的業務能夠抽象成兩類：

• 用戶(uid)維度的計數：用戶的關注計數，粉絲計數，發佈的微博計數

• 微博消息(msg_id)維度的計數：消息轉發計數，評論計數，點贊計數

 

因而能夠抽象出兩個表，針對這兩個維度來進行計數的存儲：

t_user_count (uid, gz_count, fs_count, wb_count);

t_msg_count (msg_id, forword_count, comment_count, praise_count);

 

甚至能夠更爲抽象，一個表搞定全部計數：

t_count(id, type, c1, c2, c3, …)

經過type來判斷，id到底是uid仍是msg_id，但並不建議這麼作。

 

存儲抽象完，再抽象出一個計數服務對這些數據進行管理，提供友善的RPC接口：

這樣，在查詢一條微博消息的若干個計數的時候，不用進行屢次數據庫count操做，而會轉變爲一條數據的多個屬性的查詢：

for(msg_id in list<msg_id>) {

select forword_count, comment_count, praise_count 

    from t_msg_count 

    where msg_id=$msg_id;

}

 

甚至，能夠將微博首頁全部消息的計數，轉變爲一條IN語句（不用屢次查詢了）的批量查詢：

select * from t_msg_count 

    where msg_id IN

    ($msg_id1, $msg_id2, $msg_id3, …);

IN查詢能夠命中msg_id彙集索引，效率很高。

 

方案很是帥氣，接下來，問題轉化爲：當有微博被轉發、評論、點讚的時候，計數服務如何同步的進行計數的變動呢？

若是讓業務服務來調用計數服務，勢必會致使業務系統與計數系統耦合。

以前的文章介紹過，對於不關心下游結果的業務，可使用MQ來解耦（具體請查閱《到底何時該使用MQ？》），在業務發生變化的時候，向MQ發送一條異步消息，通知計數系統計數發生了變化便可：

如上圖：

• 用戶新發布了一條微博

• msg-service向MQ發送一條消息

• counting-service從MQ接收消息

• counting-service變動這個uid發佈微博消息計數

 

這個方案稱爲「計數外置」，能夠總結爲：

• 經過counting-service單獨保存計數

• MQ同步計數的變動

• 多條消息的多個計數，一個批量IN查詢完成

 

計數外置，本質是數據的冗餘，架構設計上，數據冗餘必將引起數據的一致性問題，須要有機制來保證計數系統裏的數據與業務系統裏的數據一致，常見的方法有：

• 對於一致性要求比較高的業務，要有按期check並fix的機制，例如關注計數，粉絲計數，微博消息計數等

• 對於一致性要求比較低的業務，即便有數據不一致，業務能夠接受，例如微博瀏覽數，微博轉發數等

 

4、計數外置緩存優化

計數外置很大程度上解決了計數存取的性能問題，可是否還有優化空間呢？

像關注計數，粉絲計數，微博消息計數，變化的頻率很低，查詢的頻率很高，這類讀多些少的業務場景，很是適合使用緩存來進行查詢優化，減小數據庫的查詢次數，下降數據庫的壓力。

 

可是，緩存是kv結構的，沒法像數據庫同樣，設置成t_uid_count(uid, c1, c2, c3)這樣的schema，如何來對kv進行設計呢？

緩存kv結構的value是計數，看來只能在key上作設計，很容易想到，可使用uid:type來作key，存儲對應type的計數。

對於uid=123的用戶，其關注計數，粉絲計數，微博消息計數的緩存就能夠設計爲：

 

此時對應的counting-service架構變爲：

 

如此這般，多個uid的多個計數，又可能會變爲屢次緩存的訪問：

for(uid in list<uid>) {

 memcache::get($uid:c1, $uid:c2, $uid:c3);

}

 

這個「計數外置緩存優化」方案，能夠總結爲：

• 使用緩存來保存讀多寫少的計數（其實寫多讀少，一致性要求不高的計數，也能夠先用緩存保存，而後按期刷到數據庫中，以下降數據庫的讀寫壓力）

• 使用id:type的方式做爲緩存的key，使用count來做爲緩存的value

• 屢次讀取緩存來查詢多個uid的計數

 

5、緩存批量讀取優化

緩存的使用可以極大下降數據庫的壓力，但屢次緩存交互依舊存在優化空間，有沒有辦法進一步優化呢？

 

噹噹噹當！

不要陷入思惟定式，誰說value必定只能是一個計數，難道不能多個計數存儲在一個value中麼？

緩存kv結構的key是uid，value能夠是多個計數同時存儲。

對於uid=123的用戶，其關注計數，粉絲計數，微博消息計數的緩存就能夠設計爲：

這樣多個用戶，多個計數的查詢就能夠一次搞定：

memcache::get($uid1, $uid2, $uid3, …);

而後對獲取的value進行分析，獲得關注計數，粉絲計數，微博計數。

若是計數value可以事先預估一個範圍，甚至能夠用一個整數的不一樣bit來存儲多個計數，用整數的與或非計算提升效率。

 

這個「計數外置緩存批量優化」方案，能夠總結爲：

• 使用id做爲key，使用同一個id的多個計數的拼接做爲value

• 多個id的多個計數查詢，一次搞定

 

6、計數擴展性優化

考慮完效率，架構設計上還須要考慮擴展性，若是uid除了關注計數，粉絲計數，微博計數，還要增長一個計數，這時系統須要作什麼變動呢？

以前的數據庫結構是：

t_user_count(uid, gz_count, fs_count, wb_count)

這種設計，經過列來進行計數的存儲，若是增長一個XX計數，數據庫的表結構要變動爲：

t_user_count(uid, gz_count, fs_count, wb_count, XX_count)

在數據量很大的狀況下，頻繁的變動數據庫schema的結構顯然是不可取的，有沒有擴展性更好的方式呢？

 

噹噹噹當！

不要陷入思惟定式，誰說只能經過擴展列來擴展屬性，經過擴展行來擴展屬性，在「架構師之路」的系列文章裏也不是第一次出現了（具體請查閱《啥，又要爲表增長一列屬性？》《這纔是真正的表擴展方案》《100億數據1萬屬性數據架構設計》），徹底能夠這樣設計表結構：

t_user_count(uid, count_key, count_value)

若是須要新增一個計數XX_count，只須要增長一行便可，而不須要變動表結構：

 

7、總結

小小的計數，在數據量大，併發量大的時候，其架構實踐思路爲：

• 計數外置：由「count計數法」升級爲「計數外置法」

• 讀多寫少，甚至寫多但一致性要求不高的計數，須要進行緩存優化，下降數據庫壓力

• 緩存kv設計優化，能夠由[key:type]->[count]，優化爲[key]->[c1:c2:c3]

即：

優化爲：

• 數據庫擴展性優化，能夠由列擴展優化爲行擴展

即：

優化爲：

 

計數系統架構先聊到這裏，但願你們有收穫。