超高并发计数系统的架构设计

Posted 2021-08-11 系统架构笔记

计数系统解决什么业务问题？

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

（1）关注了多少人的计数；

（2）粉丝的计数；

（3）发布博文的计数；

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

（1）转发计数；

（2）评论计数；

（3）点赞计数；

（4）甚至是浏览计数；

在业务复杂，计数扩展频繁，数据量大，并发量大的情况下，计数系统的架构需要好的设计

如何最快速的实现业务计数呢？

典型的应用架构设计如下：

（1）调用层：处于端上的browser或者APP；

（2）站点层：拼装html或者json返回的web-server层；

（3）服务层：提供RPC调用接口的service层；

（4）数据层：提供固化数据存储的db，以及加速存储的cache；

（1）关注服务：提供关注数据的增删查改RPC接口；

（2）粉丝服务：提供粉丝数据的增删查改RPC接口；

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

首页的计数需求应该如何满足呢？

个人中心首页，需要展现博文数量这个计数，web层访问message-service的count接口，这个接口执行：

select count(*) from t_msg where uid = XXX

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

这个方案叫做“count”计数法，在数据量并发量不大的情况下，最容易想到且最经常使用的就是这种方法。

“count”计数法方案，可以总结为：

（1）多条消息多次查询，for循环进行；

（2）一条消息多次查询，多个计数的查询；

（3）一次查询一个count，每个计数都是一个count语句；

在需要多处计数的地方，这个方案的弊端是很明显的，

（1）每一个访问，对应一条count的数据库访问（count要了老命了）；

其效率之低，资源消耗之大，处理时间之长，可想而知。

通过计数外置法进行优化

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

可以抽象一个通用的计数服务。

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

（1）用户(uid)维度的计数：用户的关注计数，粉丝计数，发布的微博计数；

（2）微博消息(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操作，而会转变为一条数据的多个属性的查询.

甚至，可以将微博首页所有消息的计数，转变为一条IN语句（不用多次查询了）的批量查询：

select * from t_msg_count 

    where msg_id IN

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

IN查询可以命中msg_id聚集索引，效率很高。

那么，当有微博被转发、评论、点赞的时候，计数服务如何同步的进行计数的变更呢？
如果让业务服务来调用计数服务，势必会导致业务系统与计数系统耦合。可以通过MQ来解耦，在业务发生变化的时候，向MQ发送一条异步消息，通知计数系统计数发生了变化即可：

（1）用户新发布了一条微博；

（2）msg-service向MQ发送一条消息；

（3）counting-service从MQ接收消息；

（4）counting-service变更这个uid发布微博消息计数；

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

（1）通过counting-service单独保存计数；

（2）MQ同步计数的变更；

（3）多条消息的多个计数，一个批量IN查询完成；