第11章：设计新闻推送系统

简介​

新闻动态系统用于展示用户好友发布的、不断更新的帖子列表（包括状态更新、照片、视频和链接）。典型应用包括 Facebook 的新闻动态、Instagram 的信息流以及 Twitter 的时间线。本章将探讨可扩展新闻动态系统的架构设计。​

步骤1：理解问题​

Requirements​

平台：系统同时支持网页端和移动端应用。​

功能：用户可以发布动态、用户可以在动态中查看好友的帖子。​

排序：为简化起见，动态消息按时间倒序进行排序。​

规模：每位用户最多可拥有5,000位好友、日活跃用户数（DAU）达1,000万、动态内容可能包含文字、图片和视频。​

步骤2：概要设计​

Overview​

该设计包含两条主要流程：​

动态发布：用户发布一条动态，该动态会被写入数据库，并同步到其好友的动态列表中。​

动态消息构建：用户通过按时间倒序聚合好友的动态来获取自己的动态消息。​

News Feed APIs​

动态消息发布API：​

◦

端点： POST /v1/me/feed、这是一个 GitHub 仓库页面，标题为“system-design-notes/01. Scaling at main · liquidslr/system-design-notes”。上下文。​

动态消息获取API：​

◦

端点： GET /v1/me/feed、Params: auth_token (authentication).​

Feed Publishing​

​

​

User Interaction: The user publishes a post via the feed publishing API.​

负载均衡器：将流量分发至 Web 服务器。​

Web服务器：对请求进行身份验证并重定向至各服务。​

发布服务：将帖子存储到数据库和缓存中。​

广播服务：将该帖子传播至好友的新闻动态缓存中。​

Notification Service: Sends notifications to friends.​

​

​

News Feed Building​

​

​

用户交互：用户通过检索 API 请求其新闻资讯。​

负载均衡器：将流量分发至 Web 服务器。​

Web 服务器：将请求转发至新闻资讯服务。​

动态消息服务：从动态消息缓存中获取帖子ID，并从数据库或缓存中检索完整的帖子详情。​

​

​

步骤3：设计深度剖析​

Feed Publishing Deep Dive​

Web服务器：​

◦

使用以下方式对用户进行身份验证auth_token.​

◦

实施速率限制以防止垃圾信息。​

扇出服务：​

◦

写时扇出：在写入时将帖子推送到好友的动态中。​

▪

优点：实时更新，快速获取动态。​

▪

缺点：对于好友较多的用户来说，资源消耗较大。​

◦

读取时的扇出：在读取时拉取帖子。​

▪

优点：对不活跃用户高效。​

▪

缺点：动态消息获取较慢。​

◦

混合模式：对大多数用户采用推送模式，对高连接数用户（如名人）采用拉取模式。​

该扇出服务的工作原理如下：​

a.

获取好友ID：从图数据库中检索好友列表。​

b.

从缓存中筛选好友：在缓存中读取用户设置，以排除特定的好友（例如被静音的好友或具有选择性分享偏好的人）。​

c.

发送至消息队列：将经过筛选的好友列表与新帖子的ID一并发送至消息队列，以供后续处理。​

新闻动态获取深度解析​

Cache Architecture​

缓存被划分为五层：​

动态消息缓存：存储帖子ID，以便快速检索。​

内容缓存：存储帖子详情（热门帖子存于热缓存中）。​

社交图谱缓存：存储用户关系数据。​

操作缓存：用于记录用户操作（点赞、回复、分享等）。​

计数缓存：用于维护点赞、回复、关注者等的统计数量。​

​

​

​

​

关键优化​

Scaling​

数据库扩展：​

◦

水平扩展与分片。​

◦

为高流量查询使用只读副本。​

无状态 Web 层：使 Web 服务器保持无状态，以实现水平扩展。​

Caching​

将频繁访问的数据存储在内存中。​

使用缓存层以降低延迟并减轻数据库负载。​

Reliability​

一致性哈希：将请求均匀地分发到各台服务器。​

消息队列：解耦系统各组件并缓冲流量。​

Monitoring​

跟踪QPS（每秒查询数）和延迟等关键指标。​

监控缓存命中率，并据此调整相关配置。​