41、新闻订阅系统设计：功能、架构与优化策略

最新推荐文章于 2025-12-01 16:31:35 发布

perl8

最新推荐文章于 2025-12-01 16:31:35 发布

阅读量18

点赞数

CC 4.0 BY-SA版权

分类专栏：系统设计的艺术与权衡文章标签：新闻订阅系统系统架构 Redis缓存

本文链接：https://blog.youkuaiyun.com/perl8/article/details/154759136

系统设计的艺术与权衡专栏收录该内容

48 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

新闻订阅系统设计：功能、架构与优化策略

1. 系统需求分析

1.1 功能需求

主题选择 ：用户可选择感兴趣的主题，最多支持 100 个标签（为避免与 Kafka 主题混淆，使用“标签”代替“新闻主题”）。
新闻获取 ：用户每次可获取 10 条英文新闻，最多获取 1000 条。
新闻存档 ：系统需存档所有新闻条目。
个性化设置 ：先让用户获取相同新闻，后续考虑基于位置和语言等因素的个性化推荐。
新闻排序 ：新闻按逆时间顺序排列，可近似处理。
新闻组成 ：通常包含文本字段（如标题和正文），简化为一个 10000 字符限制的文本字段，还包括 UNIX 时间戳。初始不考虑音频、图像或视频，若有时间可考虑 0 - 10 个每个最大 1MB 的图像文件。
内容过滤 ：不提供包含不适当内容的新闻。

以下功能不在本次功能需求范围内：
- 版本控制
- 用户数据分析和复杂推荐系统
- 个性化或社交媒体功能（如分享、评论）
- 新闻来源考虑
- 搜索功能
- 货币化相关（如用户登录、支付、订阅）

1.2 非功能需求

可扩展性 ：支持 100K 日活用户，平均每人每天 10 次请求，每天处理 100 万条新闻。
高性能 ：读取操作的 P99 响应时间为 1 秒。
数据隐私 ：用户数据需保密。
最终一致性 ：允许数小时的最终一致性，用户无需在新闻上传后立即查看，但几秒内查看为佳。
高可用性 ：写入操作需高可用性，读取操作高可用性为加分项，用户可在设备上缓存旧新闻。

2. 系统架构设计

2.1 高层架构概述

新闻源将新闻提交给后端的摄取服务，然后写入数据库。用户查询新闻订阅服务，该服务从数据库获取新闻并返回给用户。

从该架构可得出以下观察：
- 摄取服务 ：需高可用性，能处理大量不可预测的流量，可考虑使用 Kafka 等事件流平台。
- 数据库选择 ：使用一个数据库存档所有新闻，其他数据库提供所需新闻。可选择适合不同用例的数据库技术，如 Redis 缓存用于服务 1000 条新闻和 100 个标签，分布式分片文件系统 HDFS 用于存档。
- 最终一致性 ：用户设备每小时更新新闻即可，可减轻新闻订阅服务的负载。

2.2 详细架构设计

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px

    A(Source/Client):::process --> B(Ingestor):::process
    B --> C(Queue):::process
    C --> D(Producer):::process
    D --> E(ETL jobs):::process
    E --> F(Consumer):::process
    F --> G(HDFS):::process
    E --> H(Queue):::process
    I(User):::process --> J(API Gateway):::process
    J --> K(News Feed Service):::process
    K --> L(Backend):::process
    L --> M(Redis):::process
    N(Metadata Service):::process --> J
    O(Moderation Service):::process --> B
    P(Notification Service):::process <--> E

摄取服务 ：接收新闻源的提交，进行简单验证，如避免 SQL 注入、过滤不适当语言、检查必填字段长度等。验证通过后，将新闻发送到 Kafka 队列；验证失败则返回 400 错误。
消费者 ：从队列中轮询新闻并写入 HDFS。至少需要两个 HDFS 表：一个用于原始新闻，一个用于准备好服务用户的新闻。可能还需要一个单独的表用于手动审核的新闻。这些表按标签和小时分区。
用户请求 ：用户通过 API 网关发送 GET /post 请求，网关查询元数据服务获取用户标签，然后通过后端服务从 Redis 缓存中查询新闻。Redis 缓存键为 (标签, 小时) 元组，值为相应的新闻列表。
ETL 作业 ：在新闻服务用户之前，执行验证或审核任务，如查找重复项、限制特定标签新闻数量等。将验证通过的新闻 ID 写入最终 HDFS 表，然后复制相应新闻覆盖 Redis 缓存。还可触发通知服务。
API 网关 ：处理身份验证、授权和限流等常规职责。若主机数量增加，可将查询元数据服务和 Redis 服务的功能分离到单独的后端服务，以独立扩展这些功能。

2.3 提前准备新闻订阅

原设计中，每个用户需要为每个 (标签, 小时) 对进行一次 Redis 查询，可能导致高读取流量和高延迟。可通过提前准备用户订阅来降低延迟和流量。

准备两个哈希映射：{用户 ID, 新闻 ID} 和 {新闻 ID, 新闻}。由于存储需求可能超出 Redis 集群容量，可采用以下解决方案：
- 按区域分区 ：将用户按区域分区，每个数据中心存储 2 - 3 个区域，每个数据中心最多 20M 用户，存储需求为 16TB。
- 限制存储 ：将存储需求限制为 1TB，仅存储几十个新闻 ID，但无法满足 1000 条新闻的需求。
- 分片 SQL 实现 ：使用分片 SQL 实现 {用户 ID, 新闻 ID} 对，按哈希用户 ID 分片，避免热点分片问题。包含 {新闻 ID, 新闻} 对的表可在每个节点复制，以便进行 JOIN 查询。

后端通过 ZooKeeper 查找合适的 SQL 集群名称，并将 SQL 查询发送到集群中的随机从节点。需监控集群流量，检测热点分片并重新平衡流量。

若仅使用移动应用客户端，可将新闻存储在客户端，用户首次获取新闻后删除相应行。也可添加时间戳列，通过 ETL 作业定期删除 24 小时前的行。

还可结合上述方法，用户打开移动应用时，使用提前准备的订阅服务第一个请求，滚动时从 Redis 获取更多新闻。

客户端可通过以下方式避免多次获取相同新闻：
- 在 GET /post 请求中包含当前拥有的新闻 ID，后端返回未获取的新闻。
- 请求特定小时的新闻，若新闻过多，可按更小的时间单位标记新闻。

3. 系统优化与注意事项

3.1 流量与存储优化

为了进一步优化系统，我们需要在流量和存储方面采取一些措施。在流量方面，提前准备用户订阅虽然降低了延迟和流量，但也带来了存储压力。我们可以通过以下方式进行优化：
- 数据压缩 ：对存储在数据库中的新闻内容进行压缩，减少存储空间的占用。例如，可以使用常见的压缩算法如 Gzip 对新闻文本进行压缩。
- 缓存策略优化 ：调整 Redis 缓存的过期时间和淘汰策略，根据新闻的热度和时效性来设置不同的缓存时间。对于热门新闻，可以适当延长缓存时间，减少对数据库的查询次数。

3.2 系统监控与维护

系统的监控与维护对于保证系统的稳定运行至关重要。我们需要对系统的各个组件进行监控，及时发现和解决问题。
- 流量监控 ：监控摄取服务、API 网关和后端服务的流量，及时发现流量异常，并进行相应的调整。例如，当发现某个时间段内流量突然增大时，可以增加摄取服务的实例数量。
- 性能监控 ：监控数据库的读写性能、Redis 缓存的命中率等指标，确保系统的性能符合要求。如果发现数据库的读写性能下降，可以考虑对数据库进行优化，如添加索引、优化查询语句等。
- 错误监控 ：监控系统中出现的错误和异常，及时通知开发人员进行处理。可以使用日志监控工具，如 ELK Stack（Elasticsearch、Logstash、Kibana）来收集和分析系统日志。

3.3 系统安全

系统安全是新闻订阅系统设计中不可忽视的重要方面。我们需要采取以下措施来保证系统的安全性：
- 数据加密 ：对用户数据和新闻数据进行加密，防止数据泄露。例如，在传输过程中使用 SSL/TLS 协议进行加密，在存储过程中使用加密算法对数据进行加密。
- 访问控制 ：通过身份验证和授权机制，确保只有授权用户可以访问系统。可以使用 OAuth 等协议进行身份验证，使用角色基于访问控制（RBAC）来进行授权管理。
- 安全审计 ：对系统的操作和访问进行审计，及时发现和处理安全事件。可以使用安全信息和事件管理（SIEM）系统来收集和分析安全日志。

4. 总结

新闻订阅系统的设计需要综合考虑功能需求、非功能需求、系统架构、优化策略和安全等多个方面。通过合理的架构设计和优化措施，可以实现一个高性能、高可用性、可扩展且安全的新闻订阅系统。

在架构设计方面，采用摄取服务、数据库和缓存等组件的组合，能够有效地处理新闻的摄取、存储和查询。提前准备用户订阅可以降低系统的读取流量和延迟，但需要注意存储容量的问题。

在优化策略方面，通过流量与存储优化、系统监控与维护以及系统安全等措施，可以保证系统的稳定运行和数据的安全性。

在实际应用中，我们还需要根据具体的业务需求和用户规模，对系统进行不断的调整和优化，以满足用户的需求和提高系统的性能。

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px

    A(流量监控):::process --> B(流量调整):::process
    C(性能监控):::process --> D(性能优化):::process
    E(错误监控):::process --> F(错误处理):::process
    G(数据加密):::process --> H(数据安全):::process
    I(访问控制):::process --> H
    J(安全审计):::process --> H

通过以上的设计和优化，我们可以构建一个满足用户需求、稳定可靠的新闻订阅系统。