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