有这样一个场景,需要你来做个架构设计。
一、有一群作者,可以发布文章。
二、有一群用户,可以关注作者。
三、用户有一个页面,可以展示所关注作者发布的文章,并且按发布时间排序。
好吧,其实就是简化版的公众号消息列表。
作者就是一个个的公众号,用户就是可爱的你,而这个展示的关注流列表,就是我们手机微信上点开订阅号消息后的部分。
这回熟悉了吧。
你会怎么设计呢?
先把表设计出来
首先有三表是必须的,用来存储元信息,毋庸置疑。
作者表:存储作者的信息
用户表:存储用户的信息
文章表:作者发布的文章信息
接下来是关联关系表。
用户与作者可以产生关注关系,因此可以有一张关注关系表。
注意,这个关注关系表是抽象的,具体实现时可以拆分成正反两张表(用户关注,作者粉丝表),总之其目的是,用户可以根据这张表查询自己关注的作者,
作者也可以根据这张表查询出自己的粉丝。
作者与文章可以产生发布关系,因此可以有一张作者发布表。
表中记录着作者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!
哦,我差点都忘了我今天在讲啥了,勉强补一句吧,这个破玩意,就是关注流。
后记
大家不要问我公众号的关注流技术架构是不是这样设计的,没意义,现在各个 APP 和网站,关注流都成为一个必需品了,一开始从微博开始流行的,整个架构的演进已经快成为了业界标准。
更重要的是,我觉得关注流的架构设计,包含了很多架构思想,把这个整明白了,好多架构思想用在其他地方上也都大同小异。
当然你不能太关注于细枝末节,比如怎么按时间排序呢?这具体有相当多的实现,一种较为优雅的实现就是用在 hbase 里,利用其 rowkey 的天然字典序,实现排序。
你要站在整个架构思想的角度去理解,才有帮助。