第11章Timeline Feed服务——11.5 推拉结合模式

11.5 推拉结合模式

我们可以很清楚地看到，拉模式和推模式的优缺点是互补的：前者无存储压力，但是有读请求压力；后者无读请求压力，但是有写请求压力和存储压力。既然它们可以互补，那么我们的思路就是将两者结合起来，即形成推拉结合模式。

11.5.1 结合思路

虽然拉模式的优势是简单、无存储压力，但是拥有海量用户的互联网公司会在意它的优势吗？这些公司既有足够的研发投入，又有充足的存储资源，其更在意的是用户体验，在拉模式下，用户获取Feed流的性能表现是其最无法接受的。因此，我们应该重点分析推模式。采用推模式可以有效地提高用户获取Feed流的性能，但是用户在发布内容时，则会带来存储压力和写请求压力，而且用户的粉丝数越多，这两方面的压力越大。

那么，推模式和拉模式如何结合呢？关键的突破口在于一条内容的发布者有多少粉丝 ，即与第10章介绍的一样，需要根据用户是否是粉丝数超过某个阈值的大V来进行策略选择：当用户发布内容时，如果此用户不是大V，则采用推模式把内容发送到粉丝的收件箱中，这样一来，即使推模式会带来存储压力大和写扩散的问题，也会由于粉丝数较少而使影响可控；当用户获取Timeline Feed流时，系统先检查其关注列表中有没有大V，如果有大V，则仅采用拉模式来拉取大V的内容列表，而非大V的内容早已在用户的收件箱中了，直接读取收件箱就好。推拉结合模式的架构如图11-3所示。

在推拉结合模式下，大V的内容发布和对Feed流的获取采用的是拉模式，这样可以有效避免因发布者的粉丝量大而带来的存储压力大和写扩散的问题；非大V的内容发布和对Feed流的获取则采用推模式，这样可以避免在获取Feed流时产生的读扩散问题。

现在我们可以初步得出结论：需要采用推拉结合模式来实现Timeline Feed服务。

11.5.2 区分活跃用户

需要强调的是，推拉结合模式的效果依赖在用户的关注列表中有多少大V。

• 如果在某用户的关注列表中是清一色的普通用户，那么对于此用户来说，推拉结合模式也就等于推模式，可以发挥推模式的优势；
• 如果在某用户的关注列表中是清一色的大V，那么推拉结合模式会完全退化为拉模式，这就意味着只关注了大V 的用户依然要接受拉模式的缺点，即获取Feed流的响应速度可能会很慢。其实不光是这种只关注了大V的情况，如果在用户的关注列表中有很多大V，那么也会存在一样的问题。

大V在发布内容后，我们依然可以采用推模式，但是现在仅将内容推送给粉丝列表中的部分活跃用户，因为这些用户使用Timeline Feed流功能的频率相对较高，所以将内容主动推送到他们的收件箱中更有可能提高获取Timeline Feed流的性能。至于那些很长时间都没有打开应用的用户，则完全没有必要把内容存储到他们的收件箱中。如果有一天这些用户登录应用并使用Timeline Feed流功能，那么保持采用推拉结合模式来获取数据就好。

综上所述，对推模式和拉模式的结合方式可以总结如下。

• 如果内容的发布者是普通用户，则完全采用推模式，把内容推送到全部粉丝的收件箱中。
• 如果内容的发布者是大V，则进一步区分活跃用户和非活跃用户。对于活跃用户，采用推模式；对于非活跃用户，采用拉模式。