内容建设--关注流

ゝ一世哀愁。 2022-10-20 00:53 182阅读 0赞

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

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

![图片][eb59189cff146bf9d141526d1f906d77.png]

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

![图片][a2dd71dfa7e5838c759e8c59cccea199.png]

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

![图片][e2d43e26d93d7ecf3ffab853019d06bf.png]

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

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

![图片][e35ebfaf80294c0617ce65ba43ce8ccd.png]

这回熟悉了吧。

你会怎么设计呢？

**先把表设计出来**

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

**作者表**：存储作者的信息

**用户表**：存储用户的信息

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

接下来是关联关系表。

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

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

![图片][fb429593c8343a769388ac544ca7a723.png]

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

![图片][afd6bd6c244dfc69327f833db5e67c0e.png]

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

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

![图片][9c92a272647841d554b74a05588314f4.png]

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

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

![图片][a5302e291a78d83cc7640c41a14753a7.png]

OK，目前为止。

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

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

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

**推模型**

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

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

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

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

![图片][7f45c8cf7881340264104497d63b9374.png]

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

当然还有另外一种方式。

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

![图片][003982a8e095f9d8d3623400cf3566b2.png]

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

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

![图片][908dc6cb4eb3e6f2d697672a954d655b.png]

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

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

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

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

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

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

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

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

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

**延迟推模型**

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

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

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

![图片][088db4edd7ce41a299df009a55a80aa1.png]

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

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

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

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

![图片][708b27fd32baa5e9fb0b1b50e761c232.png]

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

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

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

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

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

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

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

**拉模型**

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

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

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

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

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

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

![图片][7f45c8cf7881340264104497d63b9374.png]

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

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

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

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

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

![图片][505cda647c4dfe3a4e19112a2178f528.png]

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

**推拉结合**

怎么个推拉结合法呢？

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

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

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

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

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

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

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

这就是**推拉结合**。

**涉及到的架构思想**

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

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

**牺牲写性能，换取读性能**

**用空间换时间**

**平摊复杂度**

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

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

从架构设计的角度，这是

**冷热分离**

的思想。

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

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

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

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

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

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

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

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

记住它，**Trade-Off**！

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

![图片][4c3d1b6a8a2bf4dccb4ee8de3c5641b7.png]

**后记**

大家不要问我公众号的关注流技术架构是不是这样设计的，没意义，现在各个 APP 和网站，关注流都成为一个必需品了，一开始从微博开始流行的，整个架构的演进已经快成为了业界标准。

更重要的是，我觉得关注流的架构设计，包含了很多架构思想，把这个整明白了，好多架构思想用在其他地方上也都大同小异。

当然你不能太关注于细枝末节，比如怎么按时间排序呢？这具体有相当多的实现，一种较为优雅的实现就是用在 hbase 里，利用其 rowkey 的天然字典序，实现排序。

你要站在整个架构思想的角度去理解，才有帮助。

[eb59189cff146bf9d141526d1f906d77.png]: /images/20221004/2bb143613a1c41ddaf5f8aee77a274d9.png
[a2dd71dfa7e5838c759e8c59cccea199.png]: /images/20221004/a20cf2042683480085556bcba78dd03d.png
[e2d43e26d93d7ecf3ffab853019d06bf.png]: /images/20221004/aa5549c268664147ba5463620076389e.png
[e35ebfaf80294c0617ce65ba43ce8ccd.png]: /images/20221004/85bb447b29fc4979b8d97d9fa3f6880a.png
[fb429593c8343a769388ac544ca7a723.png]: /images/20221004/51b9b438989c4be9ba309828030a03dc.png
[afd6bd6c244dfc69327f833db5e67c0e.png]: /images/20221004/9f27efc7462e413c97479cf12d233257.png
[9c92a272647841d554b74a05588314f4.png]: /images/20221004/f6d2022308a14608bcf0222574fb5798.png
[a5302e291a78d83cc7640c41a14753a7.png]: /images/20221004/e96e8b18311a4655bf356d1377f25347.png
[7f45c8cf7881340264104497d63b9374.png]: /images/20221004/1c1147dc12db49099f8ee90364905aca.png
[003982a8e095f9d8d3623400cf3566b2.png]: /images/20221004/2956a71ad5f94ea3a8d435fe7dab44f9.png
[908dc6cb4eb3e6f2d697672a954d655b.png]: /images/20221004/8853a794d7de49a6acdc7e48fd7520fa.png
[088db4edd7ce41a299df009a55a80aa1.png]: /images/20221004/38f18710e6b14af1939ddbfd5fc00fca.png
[708b27fd32baa5e9fb0b1b50e761c232.png]: /images/20221004/590c54c405e24d789e0c75bc1b433ae0.png
[505cda647c4dfe3a4e19112a2178f528.png]: /images/20221004/429b32f23b594a81b91c28ef0b28f06e.png
[4c3d1b6a8a2bf4dccb4ee8de3c5641b7.png]: /images/20221004/a0aece6dcc02429aafee83176f936ec7.png