你管这叫关注流

本文来自微信公众号：低并发编程 （ID：dibingfa），作者：闪客

有这样一个场景，需要你来做个架构设计。

一、有一群作者，可以发布文章。

二、有一群用户，可以关注作者。

三、用户有一个页面，可以展示所关注作者发布的文章，并且按发布时间排序。

好吧，其实就是简化版的公众号消息列表。

作者就是一个个的公众号，用户就是可爱的你，而这个展示的关注流列表，就是我们手机微信上点开订阅号消息后的部分。

这回熟悉了吧。

你会怎么设计呢？

先把表设计出来

首先有三表是必须的，用来存储元信息，毋庸置疑。

作者表：存储作者的信息

用户表：存储用户的信息

文章表：作者发布的文章信息

接下来是关联关系表。

用户与作者可以产生关注关系，因此可以有一张关注关系表。

注意，这个关注关系表是抽象的，具体实现时可以拆分成正反两张表（用户关注，作者粉丝表），总之其目的是，用户可以根据这张表查询自己关注的作者，

作者也可以根据这张表查询出自己的粉丝。

作者与文章可以产生发布关系，因此可以有一张作者发布表。

表中记录着作者 ID、文章 ID、以及发布时间，我们可以根据这张表，把某一作者的文章，按照时间顺序查出来。我们可以形象地管它叫做该作者的发件箱。

用户与文章可以产生订阅关系，因此可以有一张用户订阅文章表。

表中记录着用户 ID、文章 ID、以及文章发布时间，我们可以根据这张表，把某一用户其关注流页面所需要展示的文章，也就是他关注的所有作者发布的文章，按照时间顺序查出来。我们可以形象地管它叫做该用户的收件箱。

OK，目前为止。

三张元数据表：用户表、作者表、文章表；

三张关联表：关注关系表、作者发件箱、用户收件箱；

都已准备就绪，当然有的表是冗余的，我们接下来看下关注流的架构演进，你就知道为什么这样设计了。

推模型

刚开始的时候，公众号作者较少，阅读公众号的读者同样也较少。

为了读者的体验，肯定是尽可能将读者刷新关注流的时间，降到最低。

此时读者有两种方式来获得自己的关注流展示结果：

读者先去关注关系表中，查询出所有的关注的作者。再去每一个作者的发件箱里把文章查询出来，还要按照时间顺序拼接，最终展示到手机上。

这样中间经历了好多次查表的过程，效率非常低下。

当然还有另外一种方式。

读者直接去自己的收件箱里，把文章一次性拿到。

这效率显然是相当高的，而且可以直接查出来的时候就按顺序排好，直接展示在手机上。

当然，这需要公众号作者每次发文章时，都把自己发布的文章，写入到所有关注他的用户的收件箱里。

显然，虽然读者读取关注流时的逻辑简单高效了，但确是以牺牲作者发布文章的逻辑，换来的。

从这个角度讲，这是牺牲写性能，换取读性能。

另一方面，本来作者发布的文章，已经存储在作者的发件箱里了，此时又冗余存储在了用户的收件箱里，而且还是多份，占用了额外的空间。

从这个角度讲，这是用空间换时间。

当然，还可以再从整个时间线的角度想，这相当于将用户读取关注流这个逻辑所消耗的时间，平摊在了公众号作者每次发布文章的逻辑中。

从这个角度讲，这是平摊复杂度。

卧槽，就这么一个破逻辑，在架构层面可以说出这么多术语，是不是装逼必备？那大家可一定要记住了，这个破玩意，在关注流架构的设计中，叫做推模型。

其含义是，作者将其发布的文章，推送给每一个关注他的读者。

这在前期公众号和读者都不多的情况下，完全没问题。

延迟推模型

上一讲中的推模型，在早期已经可以撑起一片天了。

但渐渐的，越来越多的读者知道了公众号，也开始关注更多的公众号，逐渐有粉丝量破万的公众号号主了。

一旦公众号的粉丝量多，那它每发布一篇文章，就要推给相当多的读者。

这发布一篇文章的代价就相当之大了。

但是，读者的体验又不能不管，那怎么办呢？

我们将用户分成两类，一类是活跃用户，经常刷公众号文章的，一类是不活跃用户，可能好几天才打开一次。

作者发布文章后，只立刻推给活跃用户，先不管那些非活跃用户。

那非活跃用户怎么办呢？延迟推。

即当非活跃用户再次打开他的公众号关注流时，先触发文章的推送逻辑，将未同步到其收件箱的文章推过来，之后再走正常的逻辑，从自己的收件箱取出关注流数据。

这可以说是一种冷热分离的思想。

冷数据即是那些不活跃用户，热数据即是那些活跃用户。

这种设计方式，就是关注流的第二个阶段，延迟推模型。

当然，它也是以牺牲了一些东西换来的，就是牺牲了不活跃用户首次刷新公众号关注流的体验。

但这不重要，不活跃用户本来打开公众号的次数就少，且仅仅只是影响了第一次，且还有可能进化成活跃用户。

拉模型

延迟推模型，已经可以足够撑起相当多的流量了，但再往后发展，怪物就出现了。

会出现那种，粉丝数又多，发文章又频繁，其粉丝还都是活跃用户的，大 V 号。

比如招财大牛猫，日更大佬，篇篇文章 10 万 + 阅读。

这种，不论是推模型还是延迟推模型，都扛不住了，怎么办呢？

还记不记得之前说过，读者查询自己的关注流，除了推模型之外，还有一种方式。

读者先去关注关系表中，查询出所有的关注的作者。再去每一个作者的发件箱里把文章查询出来，还要按照时间顺序拼接，最终展示到手机上。

这种方式，就是和推模型相反的，拉模型。

这种方式，就可以解决大 V 作者发布一篇文章，需要推送给太多人的烦恼。

但同样，这种方式的弊端之前也说了，就是假如用户关注的作者非常多，需要多次查表才能把最终的数据拼起来。

而我们当前遇到的问题是，大 V 作者才有推文章特繁琐的烦恼，非大 V 作者，仍然可以采用推模型。

所以我们又以作者的维度进行划分，分成大 V 作者和普通作者。

而这个模型显然也不能是单一的推模型或者拉模型了，需要推拉结合。

推拉结合

怎么个推拉结合法呢？

首先，大 V 作者不再推文章给粉丝了，仅仅保存在自己的发件箱里。

读者在刷新公众号关注流时，首先仍然是去自己的收件箱中，把文章全查出来，这是推模型。

之后，还要查出他所关注的公众号作者中，所有的大 V 作者。

如果没有，那到此为止，直接返回手机关注流数据进行展示。

如果有，再去该大 V 作者的发件箱里，把文章查出来（注意，这里只查最近发的文章，有个时间限制，不然...），这是拉模型。

好了，现在有两份数据，一份是推模型，从读者收件箱中查出来的，一份是拉模型，从大 V 作者的发件箱中查出来的。

把它们按照时间顺序，重新混合在一起，返回给手机端。

这就是推拉结合。

涉及到的架构思想

重新梳理一下，最开始，为了使得用户读取关注流的响应时间快，采用推模型，公众号作者发文章后，立即推送给所有粉丝。

从三个角度，我们讲这种设计思想在架构设计中，有

牺牲写性能，换取读性能

用空间换时间

平摊复杂度

后来，粉丝数变多，推模型的推送阶段矛盾凸显，所以要想办法削平它。

考虑到仅有一少部分读者是活跃用户，大部分读者是非活跃的（如果大部分读者都是活跃的，我公众号文章阅读量早破万了），推送阶段只推给活跃用户，非活跃用户采用延迟推送的方式，这是延迟推模型。

从架构设计的角度，这是

冷热分离

的思想。

再往后，用户层面的划分也扛不住大 V 作者了，进而考虑将作者也进行划分，分为大 V 作者和普通作者，普通作者采用推模型或延迟推模型，大 V 作者采用拉模型，这是推拉结合模型。

当然，这同样是冷热分离的思想。

再具体的细节，假如公众号作者的发件箱是用 mysql 或 hbase 这种数据库存储的，那大 V 作者的发布文章，可以进一步放在 Redis 中存储，读者在拉取大 V 作者的数据时就变得更快了，这是更细微层面的冷热分离。

再比如，其实大部分用户，可能并没有关注到大 V 作者，但还是要去用户自己的关注关系表中，把其关注的作者都查出来，然后一个个判断是不是大 V 作者。

当大部分情况下结果都是不存在大 V 作者时，我们又可以通过一点小技巧来优化，即在用户表中存储一个字段，表示该用户是否有关注大 V 作者。

这样，在用户关注了一个大 V 作者后，就多了一步修改这个字段的逻辑，但换来的是大部分读者在查询大 V 作者时很可能无需查询，这显然是合适的，这又是一种牺牲写性能换取读性能，或牺牲空间换取时间的思想。

而整个，我们这样不断地发现优化点，不断牺牲这个换取那个，就是架构设计中的权衡，用一个更装逼的词汇就是，Trade-Off。其实就是英文的权衡。

倘若你在架构设计中，始终能有 Trade-Off 这种思想围绕，不论是理解很多组件的设计、业务的架构，还是面试中回答面试官的问题，都会让人觉得你的思路至少是清晰的，和你的交流，是通畅的。

记住它，Trade-Off！

哦，我差点都忘了我今天在讲啥了，勉强补一句吧，这个破玩意，就是关注流。