43、新闻资讯流与电商销售排行榜系统设计

perl8

于 2025-11-08 13:38:52 发布

阅读量25

点赞数

CC 4.0 BY-SA版权

分类专栏：系统设计的艺术与权衡文章标签：新闻资讯流电商销售排行榜 Lambda架构

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

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

48 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

新闻资讯流与电商销售排行榜系统设计

新闻资讯流系统设计

在设计新闻资讯流系统时，有多个方面需要考虑。

文本和媒体处理方式

可以探讨将文本和媒体分别处理和存储在不同服务中，还是使用单一服务的权衡。并且可以将完整文章（包括文本和媒体）托管在 CDN 上，这样 Redis 的值可以简化为文章 ID。虽然文章文本通常比媒体小很多，但将其放在 CDN 上仍可能提升性能，特别是对于热门文章的频繁请求。不过要注意，Redis 虽然具有水平可扩展性，但数据中心间的复制较为复杂。

文章审核服务

在审核服务中，对于文章的图片和文本，为了简便起见，可以将它们作为一个整体进行审核。

媒体审核效率提升

音频转录 ：可以考虑将音频转录，这样审核人员可以阅读而不是听取音频文件，还能招聘听力障碍人员，提升公司的包容性文化。
视频加速审核 ：审核人员在审核视频文件时可以以 2 倍或 3 倍速度播放，并单独阅读转录的音频。
机器学习解决方案 ：也可以考虑使用机器学习解决方案来审核文章。

其他可能的讨论话题

动态话题标签 ：创建动态的话题标签，而非固定的话题集合。
新闻分享 ：用户可能希望与其他用户或群组分享新闻。
通知机制 ：更详细地讨论向创作者和读者发送通知的方式。
实时传播 ：文章的实时传播，ETL 作业必须是流式的，而非批量的。
文章优先级提升 ：提升某些文章的优先级。

超出功能需求讨论范围的事项

分析：对新闻资讯流进行分析。
个性化 ：为每个用户提供个性化的 100 条新闻，而不是为所有用户提供相同的 1000 条新闻，此设计会更加复杂。
多语言支持 ：提供非英语文章的服务，可能会面临处理 UTF 或语言翻译等潜在复杂问题。
盈利模式 ：
- 设计订阅系统。
- 为订阅者保留特定帖子。
- 为非订阅者设置文章限制。
- 投放广告和推广帖子。

新闻资讯流系统设计总结

架构设计 ：绘制新闻资讯流系统的初始高层架构时，考虑主要关注的数据，并绘制读写这些数据到数据库的组件。
数据库选择 ：考虑读写数据的非功能需求，选择合适的数据库类型，并考虑相关服务，如 Kafka 服务和 Redis 服务。
任务处理方式 ：将不需要低延迟的操作放在批量和流式作业中，以实现可扩展性。
服务封装 ：确定读写前后必须执行的处理操作，并将其封装在服务中。前置操作可能包括压缩、内容审核以及查找其他服务以获取相关 ID 或数据；后置操作可能包括通知和索引。
监控与告警 ：对可能感兴趣的故障和异常事件进行日志记录、监控和告警。

电商销售排行榜系统设计

在系统设计面试中，分析是常见的讨论话题，而 Top K 问题（热门商品问题）是常见的仪表盘类型。

Top K 问题的形式

问题类型	示例
电商应用按销量或收入排名的畅销或滞销产品	如本问题中亚马逊按销量排名的前 10 产品
电商应用中浏览量最多或最少的产品	-
应用商店中下载量最多的应用	-
视频应用（如 YouTube）中观看次数最多的视频	-
音乐应用（如 Spotify）中最受欢迎或最不受欢迎的歌曲	-
证券交易所（如 Robinhood 或 E*TRADE）中交易最频繁的股票	-
社交媒体应用中转发最多的帖子	如 Twitter 上转发最多的推文或 Instagram 上分享最多的帖子

需求分析

平局处理 ：高准确性可能不是最重要的，平局时可以选择任意一项。
时间间隔 ：系统应能够按特定间隔（如小时、天、周或年）进行聚合。
用例与准确性 ：用例将影响所需的准确性（以及其他要求，如可扩展性）。可以采用 Lambda 架构，提供过去几小时的近似销量和排名，以及几小时以上时间段的准确数据。也可以考虑牺牲准确性以换取更高的可扩展性、更低的成本、更低的复杂性和更好的可维护性。生成列表可能需要数分钟，低延迟不是必需的。
数据范围 ：可以接受提供过去几小时内前 10 种产品的近似销量和排名，以及几小时以上（可能长达数年）时间段内任意数量产品的销量和排名的解决方案，显示超过 10 种产品也是可以的。
显示内容 ：需要同时显示排名和销量计数。
售后事件 ：假设只考虑初始销售事件，忽略后续事件（如纠纷或产品召回）。
可扩展性要求 ：假设每天有 100 亿次销售事件（即高销售交易流量），每次事件 1 KB，写入速率为 10 TB/天。热门商品仪表盘仅由员工查看，请求率较低。假设约有 100 万种产品。系统不需要高可用性或低延迟。

初始思路

最初可能会想到将事件记录到分布式存储解决方案（如 HDFS 或 Elasticsearch），并在需要计算特定时间段内的 Top K 产品列表时运行 MapReduce、Spark 或 Elasticsearch 查询。但这种方法计算密集，可能需要很长时间，计算特定月份或年份的 Top K 产品列表可能需要数小时或数天。如果除了生成此列表外没有其他存储销售事件日志的用例，为了这个目的将这些日志存储数月或数年是浪费的。

因此，在计算这些 Top K 列表之前需要对数据进行预处理，定期按小时、天、周、月和年对产品销售进行聚合和计数。需要 Top K 列表时，可以执行以下步骤：
1. 根据所需时间段，对相应桶的计数进行求和。例如，如果需要一个月的 Top K 列表，直接使用该月的桶；如果需要特定的三个月时间段，对该时间段的月桶计数进行求和。这样可以在求和后删除事件以节省存储。
2. 对这些求和结果进行排序，以获得 Top K 列表。

初始高层架构 - Lambda 架构

Lambda 架构是一种处理大量数据的方法，结合了批量和流式处理方法。其架构由两个并行的数据处理管道和一个服务层组成，服务层将两个管道的结果进行合并：
- 流式处理管道 ：实时从所有发生销售交易的数据中心摄取事件，并使用近似算法计算最受欢迎产品的销量和排名。
- 批量处理管道 ：定期（每小时、每天、每周和每年）运行，以计算准确的销量和排名。批量管道的 ETL 作业可以包含一个任务，在批量管道的结果准备好时，用其覆盖流式管道的结果。

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

    A[数据源]:::process --> B[批量管道]:::process
    A --> C[流式管道]:::process
    B --> D[batch_table]:::process
    C --> E[streaming_table]:::process
    D --> F[仪表盘]:::process
    E --> F

销售后端服务遵循事件驱动架构（EDA）方法，将事件发送到 Kafka 主题，该主题可用于所有下游分析，如 Top K 仪表盘。

聚合服务

优化目的 ：对 Lambda 架构的初始优化是对销售事件进行聚合，并将聚合后的销售事件传递给流式和批量管道，聚合可以减少两个管道的集群规模。
架构组成 ：流式和批量管道都写入关系型数据库管理系统（RDBMS，即 SQL），仪表盘可以低延迟查询该数据库。也可以使用 Redis 进行简单的键值查找，但仪表盘和其他未来服务可能需要过滤和聚合操作。

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

    A[销售后端]:::process --> B[共享日志服务]:::process
    B --> C[聚合服务]:::process
    C --> D[流式管道]:::process
    C --> E[HDFS]:::process
    D --> F[SQL - speed_table]:::process
    E --> G[批量管道]:::process
    G --> H[SQL - batch_table]:::process
    F --> I[仪表盘]:::process
    H --> I

聚合服务由一组主机组成，这些主机订阅记录销售事件的 Kafka 主题，对事件进行聚合，并将聚合后的事件刷新/写入 HDFS（通过 Kafka）和流式管道。

聚合服务的具体操作

按产品 ID 聚合 ：原始销售事件可能包含（时间戳，产品 ID）等字段，而聚合后的事件可能是（产品 ID，开始时间，结束时间，计数，聚合主机 ID）的形式。可以对事件进行聚合，因为确切的时间戳并不重要。如果某些时间间隔很重要（如每小时），要确保（开始时间，结束时间）对始终在同一小时内。
主机 ID 与产品 ID 匹配 ：聚合服务可以按产品 ID 进行分区，每个主机负责聚合一组特定的 ID。可以手动维护一个（主机 ID，产品 ID）的映射，有以下几种实现选项：
1. 源代码中的配置文件 ：每次更改文件时，必须重启整个集群。
2. 共享对象存储中的配置文件 ：服务的每个主机在启动时读取此文件，并将负责的产品 ID 存储在内存中。服务还需要一个端点来更新其产品 ID，更改文件时，可以在将消费不同产品 ID 的主机上调用此端点。
3. 数据库表存储 ：将映射存储为 SQL 或 Redis 中的数据库表。
4. 边车模式 ：主机向边车发出获取请求，边车获取适当产品 ID 的事件并将其返回给主机。通常会选择选项 2 或 4，避免每次配置更改都重启整个集群，选择文件而非数据库的原因如下：
  - 配置文件格式（如 YAML 和 JSON）易于直接解析为哈希映射数据结构，使用数据库表实现相同效果需要更多代码。
  - 主机数量可能不超过几百或几千，配置文件很小，每个主机可以获取整个文件，不需要具有低延迟读取性能的数据库解决方案。
  - 配置更改频率不足以证明使用 SQL 或 Redis 等数据库的开销是合理的。
时间戳存储 ：如果需要存储确切的时间戳，应由销售服务处理，而不是分析或热门商品服务。要保持职责分离，因为除了热门商品分析外，还会有许多基于销售事件定义的分析管道，应能够自由开发和停用这些管道，而无需考虑其他服务。
主机上的聚合过程 ：聚合主机包含一个键为产品 ID、值为计数的哈希表，还会对其消费的 Kafka 主题进行检查点操作，将检查点写入 Redis，检查点由聚合事件的 ID 组成。聚合服务的主机数量可以多于 Kafka 主题的分区数量，但由于聚合操作简单快速，通常不需要这样做。每个主机重复执行以下操作：
1. 从主题消费一个事件。
2. 更新其哈希表。
  聚合主机可能会按设定的周期或在内存不足时刷新其哈希表，刷新过程的一种可能实现如下：
3. 将聚合事件发送到名为“Flush”的 Kafka 主题。如果聚合数据较小（如几 MB），可以将其作为单个事件写入，包含产品 ID 聚合元组列表，字段为（“产品 ID”，“最早时间戳”，“最新时间戳”，“销售数量”）。
4. 使用变更数据捕获（CDC），每个目标有一个消费者，消费事件并进行写入：
  a. 将聚合事件写入 HDFS。
  b. 将元组检查点以“完成”状态写入 Redis。
  c. 为流式管道重复步骤 2a - c。

如果没有“Flush”Kafka 主题，且消费者主机在将聚合事件写入特定目标时失败，聚合服务将需要重新聚合这些事件。写入两个检查点是为了维护一致性的一种算法。如果主机在步骤 1 失败，另一个主机可以消费刷新事件并执行写入；如果主机在步骤 2a 失败，写入 HDFS 可能成功也可能失败。

新闻资讯流与电商销售排行榜系统设计

电商销售排行榜系统设计（续）

在电商销售排行榜系统中，聚合服务是关键环节，它对数据的处理和存储有着重要影响。下面详细介绍聚合服务的其他方面以及相关的考虑因素。

聚合服务的优势与挑战

聚合服务通过对销售事件进行聚合，显著减少了流式和批量管道的集群规模，提高了系统的处理效率。然而，在实际应用中也面临一些挑战。例如，在按产品 ID 聚合时，需要确保聚合的准确性和一致性，特别是在处理大规模数据时。同时，主机 ID 与产品 ID 的匹配也需要合理的管理，以避免数据处理的混乱。

聚合服务的优化建议

为了进一步优化聚合服务，可以考虑以下几点：
- 数据压缩 ：在将聚合数据写入 HDFS 或流式管道之前，对数据进行压缩，以减少存储空间和传输带宽的占用。
- 并行处理 ：利用多核处理器或分布式计算框架，实现聚合操作的并行处理，提高处理速度。
- 缓存机制 ：在聚合主机上设置缓存，减少对 Redis 或其他存储系统的频繁访问，提高系统的响应速度。

系统扩展性考虑

随着业务的发展，电商销售排行榜系统的规模和数据量可能会不断增加。为了确保系统的可扩展性，可以考虑以下策略：
- 水平扩展 ：增加聚合服务的主机数量，以处理更多的销售事件。
- 垂直扩展 ：提升单个主机的硬件性能，如增加内存、CPU 核心数等。
- 分布式存储 ：采用分布式文件系统（如 HDFS）或分布式数据库，以存储大规模的销售数据。

系统监控与调优

无论是新闻资讯流系统还是电商销售排行榜系统，都需要进行有效的监控和调优，以确保系统的稳定运行和性能优化。

监控指标

以下是一些常见的监控指标：
|监控指标|描述|
| ---- | ---- |
|吞吐量|系统单位时间内处理的请求或事件数量|
|响应时间|系统对请求的响应时间|
|错误率|系统处理请求时出现错误的比例|
|资源利用率|如 CPU、内存、磁盘 I/O 等资源的利用率|

监控工具

可以使用以下工具进行系统监控：
- Prometheus ：用于收集和存储系统指标数据。
- Grafana ：用于可视化监控数据，生成各种报表和图表。
- ELK Stack ：用于日志收集、存储和分析。

调优策略

根据监控指标的分析结果，可以采取以下调优策略：
- 性能优化 ：对系统的代码、算法和配置进行优化，提高系统的处理效率。
- 资源分配调整 ：根据系统的负载情况，合理调整资源的分配，避免资源浪费或瓶颈。
- 故障排查与修复 ：及时发现和解决系统中的故障和问题，确保系统的稳定运行。

总结与展望

新闻资讯流系统和电商销售排行榜系统的设计涉及多个方面的考虑，包括数据处理、存储、架构设计、监控调优等。在设计过程中，需要根据具体的业务需求和系统特点，选择合适的技术和方案，以实现系统的高效、稳定和可扩展。

未来，随着技术的不断发展和业务的不断变化，这些系统也将面临新的挑战和机遇。例如，人工智能和机器学习技术的应用可以进一步提升新闻推荐的个性化和准确性，以及电商销售排行榜的预测能力。同时，随着数据量的不断增加，对系统的处理能力和存储能力也提出了更高的要求。因此，持续关注技术发展趋势，不断优化和改进系统设计，是确保系统适应未来发展的关键。

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

    A[系统监控]:::process --> B[收集指标]:::process
    B --> C[分析指标]:::process
    C --> D[性能优化]:::process
    C --> E[资源分配调整]:::process
    C --> F[故障排查与修复]:::process
    D --> G[系统性能提升]:::process
    E --> G
    F --> G

总之，通过合理的设计和有效的管理，可以构建出满足业务需求的高性能系统，为用户提供更好的服务和体验。