计数系统架构实践一次搞定_架构师之路 - (EPUB全文下载)

文件大小：0.27 mb。
文件格式：epub 格式。
书籍内容：

计数系统架构实践一次搞定 | 架构师之路
原创 2017-06-08 58沈剑 架构师之路
提醒，本文较长，可提前收藏/转发。
一、需求缘起
很多业务都有“计数”需求，以微博为例：
微博首页的个人中心部分，有三个重要的计数：
微博首页的博文消息主体部分，也有有很多计数，分别是一条博文的：
在业务复杂，计数扩展频繁，数据量大，并发量大的情况下，计数系统的架构演进与实践，是本文将要讨论的问题。
二、业务分析与计数初步实现
典型的互联网架构，常常分为这么几层：
针对“缘起”里微博计数的例子，主要涉及“关注”业务，“粉丝”业务，“微博消息”业务，一般来说，会有相应的db存储相关数据，相应的service提供相关业务的RPC接口：
对关注、粉丝、微博业务进行了初步解析，那首页的计数需求应该如何满足呢？
很容易想到，关注服务+粉丝服务+消息服务均提供相应接口，就能拿到相关计数数据。
例如，个人中心首页，需要展现博文数量这个计数，web层访问message-service的count接口，这个接口执行：
select count(*) from t_msg where uid = XXX
同理，也很容易拿到关注，粉丝的这些计数。
这个方案叫做“count”计数法，在数据量并发量不大的情况下，最容易想到且最经常使用的就是这种方法，但随着数据量的上升，并发量的上升，这个方法的弊端将逐步展现。
例如，微博首页有很多条微博消息，每条消息有若干计数，此时计数的拉取就成了一个庞大的工程：
整个拉取计数的伪代码如下：
list = getHomePageMsg(uid);// 获取首页所有消息
for( msg_id in list){ // 对每一条消息
         getReadCount(msg_id);  // 阅读计数
         getForwordCount(msg_id); // 转发计数
         getCommentCount(msg_id); // 评论计数
         getPraiseCount(msg_id); // 赞计数
}
其中：
其效率之低，资源消耗之大，处理时间之长，可想而知。
“count”计数法方案，可以总结为：
那如何进行优化呢？
三、计数外置的架构设计
计数是一个通用的需求，有没有可能，这个计数的需求实现在一个通用的系统里，而不是由关注服务、粉丝服务、微博服务来分别来提供相应的功能呢（否则扩展性极差）？
这样需要实现一个通用的计数服务。
通过分析，上述微博的业务可以抽象成两类：
于是可以抽象出两个表，针对这两个维度来进行计数的存储：
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) {
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发送一条异步消息，通知计数系统计数发生了变化即可：
如上图：
这个方案称为“计数外置”，可以总结为：
计数外置，本质是数据的冗余，架构设计上，数据冗余必将引发数据的一致性问题，需要有机制来保证计数系统里的数据与业务系统里的数据一致，常见的方法有：
四、计数外置缓存优化
计数外置很大程度上解决了计数存取的性能问题，但是否还有优化空间呢？
像关注计数，粉丝计数，微博消息计数，变化的频率很低，查询的频率很高，这类读多些少的业务场景，非常适合使用缓存来进行查询优化，减少数据库的查询次数，降低数据库的压力。
但是，缓存是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) {
 memcache::get($uid:c1, $uid:c2, $uid:c3);
}
这个“计数外置缓存优化”方案，可以总结为：
五、缓存批量读取优化
缓存的使用能够极大降低数据库的压力，但多次缓存交互依旧存在优化空间，有没有办法进一步优化呢？
当当当当！
不要陷入思维定式，谁说value一定 ............

书籍插图：

以上为书籍内容预览，如需阅读全文内容请下载EPUB源文件，祝您阅读愉快。