计数系统，架构与优化细节

╰+攻爆jí腚メ 2022-05-21 01:18 219阅读 0赞

##  ##

一、需求缘起

很多业务都有“计数”需求，以微博为例：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1][]

微博首页的个人中心部分，有三个重要的计数：

*  关注了多少人的计数
 *  粉丝的计数
 *  发布博文的计数

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 1][]

微博首页的博文消息主体部分，也有有很多计数，分别是一条博文的：

*  转发计数
 *  评论计数
 *  点赞计数
 *  甚至是浏览计数

在业务复杂，计数扩展频繁，数据量大，并发量大的情况下，计数系统的架构演进与实践，是本文将要讨论的问题。

二、业务分析与计数初步实现

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 2][]

典型的互联网架构，常常分为这么几层：

*  调用层：处于端上的browser或者APP
 *  站点层：拼装html或者json返回的web-server层
 *  服务层：提供RPC调用接口的service层
 *  数据层：提供固化数据存储的db，以及加速存储的cache

针对“缘起”里微博计数的例子，主要涉及“关注”业务，“粉丝”业务，“微博消息”业务，一般来说，会有相应的db存储相关数据，相应的service提供相关业务的RPC接口：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 3][]

*  关注服务：提供关注数据的增删查改RPC接口
 *  粉丝服务：提供粉丝数据的增删查改RPC接口
 *  消息服务：提供微博消息数据的增删查改RPC接口，消息业务相对比较复杂，涉及微博消息、转发、评论、点赞等数据的存储

对关注、粉丝、微博业务进行了初步解析，那首页的计数需求应该如何满足呢？

很容易想到，关注服务\+粉丝服务\+消息服务均提供相应接口，就能拿到相关计数数据。

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 4][]例如，个人中心首页，需要展现博文数量这个计数，web层访问message-service的count接口，这个接口执行：

select count(\*) from t\_msg where uid = XXX

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1][]

同理，也很容易拿到关注，粉丝的这些计数。

这个方案叫做“count”计数法，在数据量并发量不大的情况下，最容易想到且最经常使用的就是这种方法，但随着数据量的上升，并发量的上升，这个方法的弊端将逐步展现。

例如，微博首页有很多条微博消息，每条消息有若干计数，此时计数的拉取就成了一个庞大的工程：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 5][]

整个拉取计数的伪代码如下：

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语句

那如何进行优化呢？

三、计数外置的架构设计

计数是一个通用的需求，有没有可能，这个计数的需求实现在一个通用的系统里，而不是由关注服务、粉丝服务、微博服务来分别来提供相应的功能呢（否则扩展性极差）？

这样需要实现一个通用的计数服务。

通过分析，上述微博的业务可以抽象成两类：

*  用户(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接口：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 6][]

这样，在查询一条微博消息的若干个计数的时候，不用进行多次数据库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]》），在业务发生变化的时候，向MQ发送一条异步消息，通知计数系统计数发生了变化即可：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 7][]

如上图：

*  用户新发布了一条微博
 *  msg-service向MQ发送一条消息
 *  counting-service从MQ接收消息
 *  counting-service变更这个uid发布微博消息计数

这个方案称为“计数外置”，可以总结为：

*  通过counting-service单独保存计数
 *  MQ同步计数的变更
 *  多条消息的多个计数，一个批量IN查询完成

计数外置，本质是数据的冗余，架构设计上，数据冗余必将引发数据的一致性问题，需要有机制来保证计数系统里的数据与业务系统里的数据一致，常见的方法有：

*  对于一致性要求比较高的业务，要有定期check并fix的机制，例如关注计数，粉丝计数，微博消息计数等
 *  对于一致性要求比较低的业务，即使有数据不一致，业务可以接受，例如微博浏览数，微博转发数等

四、计数外置缓存优化

计数外置很大程度上解决了计数存取的性能问题，但是否还有优化空间呢？

像关注计数，粉丝计数，微博消息计数，变化的频率很低，查询的频率很高，这类读多些少的业务场景，非常适合使用缓存来进行查询优化，减少数据库的查询次数，降低数据库的压力。

但是，缓存是kv结构的，无法像数据库一样，设置成t\_uid\_count(uid, c1, c2, c3)这样的schema，如何来对kv进行设计呢？

缓存kv结构的value是计数，看来只能在key上做设计，很容易想到，可以使用uid:type来做key，存储对应type的计数。

对于uid=123的用户，其关注计数，粉丝计数，微博消息计数的缓存就可以设计为：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 8][]

此时对应的counting-service架构变为：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 9][]

如此这般，多个uid的多个计数，又可能会变为多次缓存的访问：

for(uid in list<uid>) \{

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

这个“计数外置缓存优化”方案，可以总结为：

*  使用缓存来保存读多写少的计数（其实写多读少，一致性要求不高的计数，也可以先用缓存保存，然后定期刷到数据库中，以降低数据库的读写压力）
 *  使用id:type的方式作为缓存的key，使用count来作为缓存的value
 *  多次读取缓存来查询多个uid的计数

五、缓存批量读取优化

缓存的使用能够极大降低数据库的压力，但多次缓存交互依旧存在优化空间，有没有办法进一步优化呢？

当当当当！

不要陷入思维定式，谁说value一定只能是一个计数，难道不能多个计数存储在一个value中么？

缓存kv结构的key是uid，value可以是多个计数同时存储。

对于uid=123的用户，其关注计数，粉丝计数，微博消息计数的缓存就可以设计为：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 10][]

这样多个用户，多个计数的查询就可以一次搞定：

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

然后对获取的value进行分析，得到关注计数，粉丝计数，微博计数。

如果计数value能够事先预估一个范围，甚至可以用一个整数的不同bit来存储多个计数，用整数的与或非计算提高效率。

这个“计数外置缓存批量优化”方案，可以总结为：

*  使用id作为key，使用同一个id的多个计数的拼接作为value
 *  多个id的多个计数查询，一次搞定

六、计数扩展性优化

考虑完效率，架构设计上还需要考虑扩展性，如果uid除了关注计数，粉丝计数，微博计数，还要增加一个计数，这时系统需要做什么变更呢？

之前的数据库结构是：

t\_user\_count(uid, gz\_count, fs\_count, wb\_count)

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 11][]

这种设计，通过列来进行计数的存储，如果增加一个XX计数，数据库的表结构要变更为：

t\_user\_count(uid, gz\_count, fs\_count, wb\_count, XX\_count)

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 12][]

在数据量很大的情况下，频繁的变更数据库schema的结构显然是不可取的，有没有扩展性更好的方式呢？

当当当当！

不要陷入思维定式，谁说只能通过扩展列来扩展属性，通过扩展行来扩展属性，在“架构师之路”的系列文章里也不是第一次出现了（具体请查阅《[啥，又要为表增加一列属性？][Link 1]》《[这才是真正的表扩展方案][Link 2]》《[100亿数据1万属性数据架构设计][100_1]》），完全可以这样设计表结构：

t\_user\_count(uid, count\_key, count\_value)

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 13][]

如果需要新增一个计数XX\_count，只需要增加一行即可，而不需要变更表结构：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 14][]

七、总结

小小的计数，在数据量大，并发量大的时候，其架构实践思路为：

*  计数外置：由“count计数法”升级为“计数外置法”
 *  读多写少，甚至写多但一致性要求不高的计数，需要进行缓存优化，降低数据库压力
 *  缓存kv设计优化，可以由\[key:type\]->\[count\]，优化为\[key\]->\[c1:c2:c3\]

即：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 8][]

优化为：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 10][]

*  数据库扩展性优化，可以由列扩展优化为行扩展

即：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 11][]

优化为：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 13][]

计数系统架构先聊到这里，希望大家有收获。

===【完】===

原文地址：https://mp.weixin.qq.com/s/cCnPGRQ6LZHg8-7FRJLaKQ

[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1]: /images/20220521/dc1a7df1db144ce49fc581dcae348019.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 1]: /images/20220521/c160f5dfa415483f94b860567f9915b7.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 2]: /images/20220521/4e111c88fb9d4859916578879e593a8f.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 3]: /images/20220521/03b559630ffc419887da0a9cab5b4423.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 4]: /images/20220521/b08bfe4ebc70472fb69e734f0ed3f03c.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 5]: /images/20220521/42ae4c9c4529413da46bd0f2f6d4dbf5.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 6]: /images/20220521/dbe574b2fea34a9dbd266fc5cc675d40.png
[MQ]: http://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651960012&idx=1&sn=c6af5c79ecead98daa4d742e5ad20ce5&chksm=bd2d07108a5a8e0624ae6ad95001c4efe09d7ba695f2ddb672064805d771f3f84bee8123b8a6&scene=21#wechat_redirect
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 7]: /images/20220521/2e92b039861840a3977f74b854d0b4f3.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 8]: /images/20220521/9ba4051f3ae948238036cec6a884b94e.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 9]: /images/20220521/ad16fae0dc9345d6ac14c0e02e7372b7.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 10]: /images/20220521/8bf38ee5be474d3d8d79d46f1e4755fa.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 11]: /images/20220521/14f91bccbfa148f7b6373f715e8c9362.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 12]: /images/20220521/3a771806f1fd4a669f1f68625da106cb.png
[Link 1]: http://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651959762&idx=1&sn=f7d8d7648416a0157af6ac61a6b555c8&chksm=bd2d040e8a5a8d181ec1baa2e96982991ddfc218bb6838f38da61b651e4b8de5f0bbbd94f814&scene=21#wechat_redirect
[Link 2]: http://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651959765&idx=1&sn=b9916aa95c320e41035977e0a8098ca6&chksm=bd2d04098a5a8d1f3af38f658c05002151e621170949d2e3bb5b1bceea55c64b0477dba4c647&scene=21#wechat_redirect
[100_1]: http://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651959855&idx=1&sn=f33abe8ec598c273f29cebb9365ece59&chksm=bd2d07f38a5a8ee58a944507a134e1da1efc3ac9c4d1c4cff261137cd986e51f5fe7cee9de15&scene=21#wechat_redirect
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 13]: /images/20220521/2743813aaf314b24a8978d0c87701d21.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 14]: /images/20220521/e9cc75dfc91346958eea1e7126abd686.png