第10章：设计通知系统

简介​

通知系统是现代应用不可或缺的组成部分，能够及时推送产品通知、活动信息、优惠促销及各类提醒。通知可通过以下方式发送：推送通知（移动端或桌面端）短信，以及电子邮件.​

本章重点探讨如何设计一个能够每日发送数百万条通知的可扩展系统。​

​

​

步骤1：理解问题​

Requirements​

•

通知类型：推送通知、短信和电子邮件。​

•

送达方式：软实时系统，延迟极低。​

•

支持平台：iOS、Android 和桌面端。​

•

触发机制：通知可由客户端应用触发，也可在服务器端定时触发。​

步骤2：概要设计​

Components​

通知类型：​

◦

iOS 推送通知：使用苹果推送通知服务（APNS）.​

◦

Android 推送通知：使用Firebase 云消息传递（FCM）.​

◦

短信消息：第三方服务，如Twilio或Nexmo。​

◦

电子邮件：使用SendGrid或Mailchimp等商业邮件服务。​

联系信息收集：​

​

​

•

在应用安装或注册时收集设备令牌、手机号码或电子邮件地址。​

•

将联系信息存储在数据库中：​

◦

设备令牌表：用于推送通知。​

◦

用户表：用于存储邮箱和手机号码。​

​

​

通知发送流程：​

•

触发服务：​

◦

生成事件以触发通知（例如，账单提醒、物流更新）。​

•

通知服务器：​

◦

为各服务提供发送通知的API接口。​

◦

对邮箱和手机号码进行基本校验。​

◦

查询数据库或缓存，获取渲染通知所需的数据。​

•

第三方服务：向用户发送通知。​

Challenges in Initial Design​

•

单点故障（SPOF）：一台通知服务器的宕机会导致整个系统瘫痪。​

•

可扩展性问题：难以独立扩展数据库、缓存和处理组件。​

•

性能瓶颈：发送通知时资源消耗较高。​

Improved Design​

​

​

•

将数据库和缓存移出通知服务器。​

•

引入水平扩展，部署多台通知服务器。​

•

使用消息队列实现系统各组件的解耦。​

◦

当需要发送大量通知时，消息队列可作为缓冲区。​

•

增加工作进程，从消息队列中拉取消息事件，并将其发送至相应的第三方服务。​

​

​

步骤3：设计深度剖析​

Reliability​

防止数据丢失：​

​

​

去重：​

◦

校验事件ID，避免重复发送通知。​

◦

当通知事件首次到达时，通过检查事件ID判断是否已被处理过。若已处理，则直接丢弃；否则发送通知。​

Additional Components​

​

​

通知模板：用于实现一致且高效的通知的预格式化模板。​

通知设置：​

◦

用户可针对特定渠道（推送、短信或邮件）选择加入或退出。​

◦

存储于专用的通知设置表中。​

速率限制：限制向用户发送通知的频率。​

重试机制：当第三方服务出现故障时，自动重试发送通知。​

监控队列：跟踪排队的通知，以动态扩展工作进程。​

事件追踪：收集打开率、点击率和用户参与度等指标。​

Security​

•

使用AppKey和AppSecret对推送通知的API进行身份验证并确保其安全性。​

Notification Flow​

​

​

触发服务调用API以发送通知。​

通知服务器验证请求，并从缓存或数据库中获取元数据。​

通知事件被发送至消息队列。​

工作进程处理事件并与第三方服务交互。​

第三方服务向用户发送通知。​

​

​

关键优化​

水平扩展：增加更多通知服务器以实现负载均衡。​

消息队列：通过解耦处理来应对高并发流量。​

缓存：通过缓存高频访问的数据来降低延迟。​

分布式爬取：从地理上优化消息传递，以提升性能。​