你管这叫关注流

本文来自微信公众号:低并发编程 (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

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

Published by

风君子

独自遨游何稽首 揭天掀地慰生平

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注