在本章中，您将被要求设计一个新闻提要系统。什幺是新闻系统？根据Facebook 页面，“News feed 是中间不断更新的故事列表。您的主页。动态消息包括状态更新、照片、视频、链接、应用活动记录和喜欢您在 Facebook 上关注的人、页面和群组“[1]。这是一个常见的面试问题。类似的问题有：设计Facebook新闻提要，Instagram 提要、Twitter 时间线等
第 1 步 - 了解问题并确定设计范围
第一组澄清问题是了解面试官的想法当她要求你设计一个新闻提要系统时。至少，你应该弄清楚支持哪些功能。以下是应聘者与面试官互动的例子：
应聘者：这是移动应用进程吗？还是 Web 应用进程？还是两者兼而有之？
面试官：Both
应聘者：有哪些重要功能？
面试官：用户可以在动态消息页面上发布帖子并查看其朋友的帖子。
应聘者：新闻提要是按时间倒序排序还是按任何特定顺序排序比如题目分数？例如，来自密友的帖子比重更高。
面试官：为了简单起见，让我们假设提要是按时间倒序排序的订单。
应聘者：一个用户可以有多少个好友？
面试官：5000
应聘者：流量是多少？
面试官：1000万DAU
应聘者：Feed 可以包含图片、视频还是仅包含文本？
面试官：它可以包含媒体文档，包括图像和视频。
现在您已经收集了需求，我们专注于设计系统。
第 2 步 - 提出高级设计并获得支持
该设计分为两个流程：Feed 发布和新闻 Feed 构建。
- Feed 发布：当用户发布帖子时，相应的数据会写入缓存和数据库。帖子会发布到她朋友的新闻提要中。
- news Feed构建：为简单起见，我们假设新闻源是通过聚合构建的朋友的帖子按时间倒序排列。
新闻源 API
新闻源 API 是客户端与服务器通信的主要方式。那些API 基于 HTTP，允许客户端执行操作，包括发布状态检索新闻提要、添加好友等。我们将讨论两个最重要的 API：feed发布 API 和新闻提要检索 API。
Feed 发布 API
要发布帖子，HTTP POST 请求将发送到服务器。API如下图所示：
POST /v1/me/feed
参数：
- 内容：内容是帖子的文本。
- auth_token：用于对 API 请求进行身份验证。
新闻源检索 API
检索新闻提要的 API 如下所示：
获取 /v1/me/feed
参数：
- auth_token：用于对 API 请求进行身份验证。
Feed 发布
图 11-2 显示了源发布流程的高级设计。
- 用户：用户可以在浏览器或移动应用进程上查看新闻源。用户使用内容 “Hello” 通过 API：
/v1/me/feed？content=Hello&auth_token={auth_token} - 负载均衡器：将流量分配到 Web 服务器。
- Web 服务器：Web 服务器将流量重定向到不同的内部服务。
- 帖子服务：将帖子保留在数据库和缓存中。
- 扇出服务：将新内容推送到朋友的新闻提要。新闻源数据存储在缓存，以便快速检索。
- 通知服务：通知好友有新内容可用，并发送推送通知。
构建新闻提要
在本节中，我们将讨论如何在幕后构建新闻提要。图 11-3 显示了高级设计：
- 用户：用户发送请求以检索其新闻提要。请求如下所示：/ v1/me/feed。
- 负载均衡器：负载均衡器将流量重定向到 Web 服务器。
- Web 服务器：Web 服务器将请求路由到新闻源服务。
- 新闻源服务：新闻源服务从缓存中获取新闻源。
- 新闻源缓存：存储呈现新闻源所需的新闻源 ID。
第 3 步 - 深入探究设计
高级设计简要介绍了两个流程：源发布和新闻源生成。在这里，我们将更深入地讨论这些主题。
提要发布深入探讨
图 11-4 概述了新闻发布的详细设计。我们已经讨论了大部分组件，我们将重点介绍两个组件：Web 服务器和扇出服务。
网站服务器
除了与客户端通信之外，Web 服务器还强制执行身份验证和速率限制。只有使用有效 auth_token 登录的用户才可以发帖。系统限制了用户在一定时间内可以发布的帖子数量，对于防止垃圾邮件和滥用行为至关重要内容。
扇出服务
扇出是将帖子发送给所有朋友的过程。两种类型的扇出模型是：写入时的扇出（也称为推模型）和读取时的扇出（也称为拉模型）。两个都模型各有利弊。我们解释他们的工作流程并探索最佳方法支持我们的系统。
写入时扇出。通过这种方法，新闻源是在写入时预先计算的。一个新的帖子发布后会立即发送到朋友的缓存中。
优点：
- 动态消息实时生成，可以立即推送给好友。
- 获取新闻源速度很快，因为新闻源是在写入时预先计算的。
缺点： - 如果用户有很多朋友，则获取朋友列表并为所有朋友生成新闻提要它们既缓慢又耗时。这就是所谓的热键问题。
- 对于不活跃或很少登录的用户，预计算新闻源会浪费计算能力资源。
读取时扇出。新闻源是在阅读期间生成的。这是一个按需模型。当用户加载其主页时，最近的帖子将被拉出。
优点：
- 对于不活跃的用户或很少登录的用户，读时扇出效果更好，因为它可以不要在他们身上浪费计算资源。
- 数据不会推送给好友，因此不存在热键问题。
缺点： - 由于新闻提要不是预先计算的，因此获取新闻提要很慢。
我们采用混合方法来获得这两种方法的优点并避免其中的陷阱。由于快速获取新闻源至关重要，因此我们对大多数用户使用推送模型。对于名人或拥有很多朋友/关注者的用户，我们让关注者拉取新闻内容按需以避免系统过载。一致性哈希是一种有用的技术，可以减轻热键问题，因为它有助于更均匀地分配请求/数据。让我们仔细看看如图11-5所示的扇出服务
扇出服务的工作原理如下：
- 从图形数据库中获取好友 ID。图形数据库适合管理朋友关系和朋友推荐。有兴趣的读者希望了解更多信息关于这个概念应参考参考资料[2]。
- 从用户缓存中获取好友信息。然后，系统会根据用户过滤掉好友设置。例如，如果您将某人静音，则该帖子将不会显示在您的动态消息中即使你们仍然是朋友。帖子可能不显示的另一个原因是用户可以有选择地与特定朋友分享信息或对其他人隐藏信息。
- 将好友列表和新帖子 ID 发送到消息队列。
- 扇出工作器从消息队列中获取数据，并将新闻源数据存储在新闻feed缓存。您可以将新闻feed缓存视为映射表。每当有新帖子发布时，它都会被附加到新闻提要表中，如图 11-6。如果我们存储整个用户，并在缓存中发布对象，内存消耗可能会变得非常大。因此，仅存储 ID。为了保持较小的内存大小，我们设置了一个可配置的限制。用户滚动浏览数千个帖子的新闻提要很小。大多数用户只对新内容感兴趣，因此缓存丢失率很低。
- Store <post_id, user_id >在news feed缓存中。图11-6展示了这样一个例子新闻feed看起来像在缓存中。
新闻源检索深入探讨
图 11-7 说明了新闻检索的详细设计。
如图11-7所示，媒体内容（图片、视频等）存储在CDN中，检索速度更快。让我们看看客户端如何检索新闻提要。- 用户发送请求以检索其新闻提要。请求如下所示：/v1/me/feed
- 负载均衡器将请求重新分发到 Web 服务器。
- Web 服务器调用新闻源服务来获取新闻源。
- 新闻feed服务从新闻feed缓存中获取列表帖子 ID。
- 用户的新闻提要不仅仅是一个提要 ID 列表。它包含用户名，配置文档图片、帖子内容、帖子图片等。因此，新闻feed服务获取完整的用户和帖子对象从缓存（用户缓存和post缓存）构造完整的新闻内容。
- 整合好的新闻源以 JSON 格式返回给客户端，用于渲染。
缓存体系结构
缓存对于新闻提要系统极为重要。我们将缓存层分为 5 层如图11-8所示
- 新闻提要：它存储新闻提要的 ID。
- 内容：它存储每个帖子数据。热门内容存储在热缓存中。
- 社交图谱：它存储用户关系数据。
- 操作：它存储有关用户是否喜欢帖子、回复帖子或获取其他信息对帖子的操作。
- 计数器：它存储点赞、回复、关注、关注等计数器
第 4 步 - 结束
在本章中，我们设计了一个新闻提要系统。我们的设计包含两个流程：feed发布和新闻提要检索。像任何系统设计面试问题一样，没有完美的系统设计方法。公司有其独特的约束条件，您必须设计一个系统来适应这些约束条件。了解设计和技术选择的权衡非常重要。如果有剩下的几分钟，您可以谈谈可伸缩性问题。为避免重复讨论，仅下面列出了高级别的谈话要点。
扩展数据库：
- 垂直缩放与水平缩放
- SQL 与 NoSQL
- 主从复制
- 只读副本
- 一致性模型
- 数据库分片
其他谈话要点：
- 保持 Web 层无状态
- 尽可能多地缓存数据
- 支持多个数据中心
- 丢失消息队列的一对组件
- 监控关键指标。例如，高峰时段的 QPS 和用户时的延迟刷新他们的新闻提要很有趣。
恭喜你走到这一步！现在拍拍自己的背。干得好！
参考资料
[1] 动态消息的工作原理：
https://www.facebook.com/help/327131014036297/
[2] 朋友的朋友推荐 Neo4j 和 SQL 服务器：
http://geekswithblogs.net/brendonpage/archive/2015/10/26/friend-of-friendrecommendations-with-neo4j.aspx
