在社交网络上设计 feed/twitter 系统时，我们都知道推送（写入时扇出）与拉取（读取时扇出）。
在推送模式下，每次作者生成新帖子时，我们都会写入作者的朋友（或关注者）的更新列表（帖子、推文等），这样他们的关注者就不需要查询他们的所有更新关注者每次都会喂食。
在拉模式下，我们让关注者在每次需要查看所有朋友的动态时查询他所有关注的朋友的动态。
但是在这两种情况下，通常使用什么机制来允许人们在网站上实时查看更新的提要？ （我认为 FB 或 Twitter 不需要你手动刷新页面来查看朋友的新帖子）。
假设 John 写了一篇文章，在推送模式下，它将这篇文章的指针推送（写入 SQL 或 Redis 缓存）到他所有朋友的提要，他朋友的浏览器如何知道现在有来自 John 的更新？
我假设您有一个动态（SPA）前端。
在拉动模式下，您有两种选择：
定期重新获取提要数据，每次发送上次查询时间以仅过滤新的提要项目。这种方法在开始新项目时效果很好，但无法很好地扩展。
拥有一个消息代理，在创建新帖子后，您需要向所有可能更新提要的在线客户端发布事件，稍后在收到此类事件后在客户端重新加载提要。您还可以在事件负载本身中包含新内容。
推送模式下：
定期重新获取 Feed 数据（由于您的 Feed 查询并不复杂，因此性能开销要少得多）。
当你要推送时，检查客户端是否有活动连接并同时发布事件。
人们通常使用混合方法：
对于拥有大量活跃消费者（上个月至少登录一次）的生产者，请使用拉取方法。
对于活跃消费者数量较少的生产者，请使用推送方式。
在推送方法中，用户提要中项目数量的容量非常重要。如果用户请求更多提要项目，您可以退回到仅拉动。此外，由于有容量，您不需要推送给不活跃的用户（可能会在他们登录之前被新的提要项目替换）。
这是系统设计面试中的常见问题。通常要求申请 FAANG 或类似公司的后端软件工程师。
我从 Facebook 的论文中了解到为什么他们更喜欢在 TAO Graph 数据库中使用 Pull（读时扇出）模型，该模型用于发布帖子、点赞等的时间线。
单个 Facebook 页面可以聚合和过滤数百个项目 来自社交图谱。 我们为每个用户提供量身定制的内容 他们，我们通过隐私检查来过滤每个项目 计算当前观看者的帐户。
这种极端的定制使其 当内容无法执行大多数聚合和过滤时 被建造;相反，我们解决数据依赖性并检查隐私 每次查看内容时。我们尽可能地拉动 社交图谱，而不是推送它。
这种实现策略对图数据存储提出了极高的读取要求； 它必须高效、高度可用，并且可以扩展到高查询率。
– 2013 年的论文，TAO：Facebook 的社交图谱分布式数据存储
Twitter 中使用了另一种方法——Push 方法。 我还没有调查任何来源为什么 Twitter 使用它来预填充推文的个人时间线。