通知系统的设计方案

小马爱打代码

于 2024-10-11 16:48:39 发布

阅读量342

点赞数 7

分类专栏：系统设计文章标签：系统设计方案

本文链接：https://blog.csdn.net/weixin_46619605/article/details/142857566

版权

系统设计专栏收录该内容

1 篇文章 0 订阅

订阅专栏

通知系统的定义

通知系统（Notification System），顾名思义即通知信息的传达处理系统。目的是为了让用户获得需要得到的消息及提醒并进行处理。这里的“需要得到”主要包括两层意思：一是用户彼此互动触发的信息流（如留言、评论、回复、私信等）；二是网站或应用希望用户了解关注的信息（如系统公告、升级通知、营销活动、行为召唤等）。

设计

功能需求
通知类型：例如消息通知、警告通知、活动通知等。

用户群体：需要通知的用户群体是谁，是否有分组。

通知渠道：例如邮件、短信、推送通知、应用内通知等。

通知频率：通知的发送频率和限流策略。

优先级：不同通知的优先级管理。

用户偏好：用户是否可以自定义接收通知的偏好。

重试机制：处理通知发送失败的情况，必要时重试（如短信或电子邮件发送失败）。

非功能需求
可扩展性：系统应能够每分钟处理数百万条通知，支持数百万并发用户。

高可用性：确保最小的停机时间，即使在故障情况下也能发送通知。

可靠性：保证至少一次的通知传递，对于某些使用场景可能需要保证只有一次传递。

低延迟：通知应尽快发送，以确保及时交付。

容量预估
在深入设计之前，让我们先估算下系统规模以更好地做出设计决策。假设系统服务于 1000万日活用户，每个用户平均每天接收 5条通知。
峰值负载
假设在峰值时间内（如秒杀期间）1分钟内发送 100万条通知，这意味着系统应能够处理：

每天的通知数量：10,000,000 x 5 = 50,000,000条通知
峰值每秒通知数量：1,000,000 / 60 = ~17,000条通知/秒

存储需求
假设每条通知的数据量大小是 1KB，则存储容量评估为：

用户数据存储需求：10,000,000 * 1 KB = 10GB
每日通知存储需求：10,000,000 * 5 * 1 KB = 50GB

High-level 设计
从 High-level 层面来看，通知系统将包括以下组件：

通知服务（Notification Service）

通知服务是所有通知请求的入口，无论是来自外部应用程序还是内部系统。它暴露的API可以供各种客户端调用以触发通知。
这些请求可以是发送事务性通知（如密码重置邮件）、促销通知（如折扣优惠）或系统警报（如停机警告）。
每个请求都被验证以确保其包含所有必要的信息，如接收者ID、通知类型、消息内容以及应通过哪些渠道发送通知（电子邮件、短信等）。
对于需要在未来日期或时间发送的通知，通知服务与调度服务（Scheduler Service）集成。
处理请求后，通知服务将通知推送到通知队列（如 Kafka或 RabbitMQ）。

2.用户偏好服务

用户偏好服务允许用户控制如何接收通知。
它存储和检索用户接收不同渠道通知的个人偏好。
服务跟踪用户明确选择加入或退出的通知类型。
例如：用户可以选择退出营销或促销内容。
为防止用户被通知淹没，用户偏好服务对某些类型的通知（尤其是促销消息）实施频率限制。
例如：用户每天只能接收2条促销通知。

3.调度服务

调度服务负责存储和跟踪定时通知——那些需要在特定未来时间发送的通知。
这些可以包括提醒、促销活动或其他不立即发送但必须基于预定时间触发的时间敏感通知。
例如：促销消息可能计划在下周发送。
一旦到达预定时间，调度服务将从其存储中提取通知并将其发送到通知队列。

4.通知队列

通知队列在通知服务和渠道处理器之间充当缓冲区。
通过将通知请求提交与通知发送解耦，队列使系统能够更有效地扩展，尤其是在高流量期间。
队列系统提供消息传递的保证。
根据使用场景，可以配置为：
- 至少一次传递：确保每条通知至少发送一次，即使这在罕见情况下会导致重复消息。
- 只有一次传递：确保每条通知只发送一次，防止重复，同时保持可靠性。

5.渠道处理器

渠道处理器负责从通知队列中提取通知并通过特定渠道（如电子邮件、短信、推送通知和应用内通知）发送给用户。
通过将通知服务与实际发送解耦，渠道处理器实现了独立扩展和异步处理通知。
这种设置允许每个处理器专注于其指定的渠道，确保可靠的发送，并内置重试机制和高效处理故障。

6.数据库/存储

数据库/存储层管理大量数据，包括通知内容、用户偏好、定时通知、发送日志和元数据。
系统需要混合存储解决方案来支持不同需求：
- 事务性数据：使用关系数据库（如 PostgreSQL或 MySQL）存储结构化数据，如通知日志和发送状态。
- 用户偏好：使用NoSQL数据库（如 MongoDB）存储大量用户特定数据，如偏好和限速。
- Blob存储：对于包含大附件的通知（如带图片或 PDF的电子邮件），使用 OSS，Amazon S3或类似服务存储这些附件。

Low-level设计
设计完 High-level，我们将进入更详细的 Low-level 设计层面，主要包含以下步骤：
步骤1：通知请求创建
首先，通知系统的调用方（如电商平台、或营销系统等）需要生成通知请求。
请求的消息结构如示例请求：

{
  "requestId": "xxx1",
  "timestamp": "2024-09-18T22:00:00Z",
  "notificationType": "transactional",
  "channels": ["email", "sms", "push"],
  "recipient": {
    "userId": "user1",
    "email": "user1@example.com"
  },
  "message": {
    // 消息体
  }
}