计数系统架构实践一次搞定_架构师之路

计数系统架构实践一次搞定 | 架构师之路 原创 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......