新闻推送系统架构设计详解

新闻推送系统架构设计详解

引用

CSDN

1.

https://m.blog.csdn.net/qq_44810930/article/details/145041602

新闻推送系统是现代互联网应用中不可或缺的一部分，无论是社交媒体、新闻平台还是其他内容分发系统，都需要高效、实时的推送机制来满足用户需求。本文将从系统需求分析开始，逐步探讨数据模型设计、API选择、推送策略以及整体系统架构，为构建一个高可用、低延迟的新闻推送系统提供参考。

系统需求与估算

• 功能需求：包括提要发布、检索、通知和分析等功能。
• 非功能需求：需具备高可用性和低延迟特性。
• 估算数据：假设每天有 2000 万活跃用户，每人每天调整五次，由此可得每秒约接收 1000 条推文，按 100:1 的读写比例，每秒约有 10 万个读取请求。若每条推文按 100 字节算，存储 10 年约需 36TB 存储空间。

数据模型概述

• 用户表：包含 id、电子邮件、出生日期、信用信息等，id 作为主线 UID。
• 推文表：有 id、关联用户的外键、文本内容以及用于区分推文类型（如常规推文、转发）的枚举。
• 关注者表：通过两个外键分别记录关注者和被关注者的 id，以明确用户间的关注关系。
• 提要表：与用户和推文相关联，一个用户可拥有多个提要，每个提要包含多条推文，通过外键建立关联，此数据模型虽简单但功能强大，是系统设计的良好起点。

API 设计探讨

• Rest API：具有发布端点（需推文内容和身份验证令牌）和获取端点（提供身份验证令牌获取提要），能满足大部分需求，较为简单实用。
• GraphQL：2015 年由 FACEBOOK 创建，仅有一个端点，通过查询（检索信息）和突变（更改数据）操作，由客户端指定响应形状，可解决数据过度获取问题，扩展性良好，但相对复杂，本文暂以 Rest API 为例进行后续讨论。

推送拉取策略分析

• 推送模型（写入时扇出）：新推文发布时立即推送给关注者提要缓存，优点是读取速度快、提要实时生成，但会为不活跃用户计算浪费资源，且存在热键问题（如大 V 发推时资源消耗巨大）。
• 拉取模型（读取时扇出）：系统在关注者请求查看提要时才计算新闻源，避免了资源浪费和热键问题，但读取速度慢，难以满足低延迟和高性的非功能需求。
• 混合方法：结合推式和拉式模型，对大多数用户采用推送模型，对粉丝众多的名人采用拉取模型，能较好地平衡资源利用和性能，有效解决提要发布和检索问题。

体系结构与讨论点

• 体系结构

• 用户服务：配备用户缓存和数据库，可按需设置图形数据库，用于处理用户基本信息和关注关系，支持快速信息检索。

• 新闻源服务：与推文服务交互实现发布和检索功能，与通知服务协作，在发布推文时可推送至 Kafka 队列等，并通过通知服务向用户发送邮件、短信等多种形式的通知。

• 通知服务：与 Kafka 等流媒体服务配合，将通知推送至各类终端。

• 分析服务：运用 spark 等大数据工具分析使用指标（如每日推文数量、用户与帖子的互动情况等），有助于提升用户体验。

• 讨论点

• 无状态服务：利于水平扩展应用程序，不保留用户会话信息。

• 多实例服务：每个服务设置多个实例，确保系统高可用性，在节点故障时仍能正常处理请求。

• 多数据中心分布：降低全球用户的延迟，提升服务响应速度。

• 数据库只读副本：设置多个只读副本处理大量读取负载，可采用领导者追随者方法。

• 数据缓存：缓存数据提升性能，但需定义缓存策略（如过期政策）。

• 指标监控与服务定制：监控使用指标，根据请求量变化定制服务，如在高请求时段启动更多服务实例。

• 媒体存储：存储视频、图像等媒体文件时使用 CDN，加快检索速度，减少延迟，提高整体性能和用户体验。