设计通知系统

通知系统可以向用户发送一些重要信息，如突发新闻、产品更新、活动和商品优惠信息等。

这里说的通知不仅仅指手机推送的通知，有3种类型的通知，手机推送通知、短信和邮件。

理解问题

构建一个每天发送数百万次通知的可扩展的系统并非易事。

发送iOS推送通知，主要需要3个组件

服务商构建通知，然后将其发送到APNS Apple Push Notification Service，苹果推送通知服务。

与APNS不同，安卓系统通常使用FCM Firebase Cloud Messaging 给安卓设备推送通知。

许多开发者和企业常常使用 Twilio、Nexmo 等第三方短信服务。

尽管可以设置自己的邮箱服务器，但很多公司还是倾向于选择商业邮件服务，如 Sendgrid、Mailchimp 是最受欢迎的邮件服务，它们提供更高的投递成功率和更好的数据分析功能。

为了发送通知，我们需要收集移动设备的令牌、手机号或邮箱信息。

当用户安装应用或第一次注册时，API服务器会收集用户的联系信息并存储在数据库中。

服务1到服务N：这里的服务可以是微服务、定时任务，也可以是触发通知发送事件的分布式系统。例如，账单服务发送邮件提醒用户付款，或者购物网站通过短信告诉用户其包裹会在明天送达。
通知系统：它为服务 1 到服务 N 提供 API ，并且为第三方服务构建通知载荷。
第三方服务：第三方服务负责发送通知给用户。注意可扩展性。具有高可扩展性意味着系统很灵活，可以轻松插入或者移除第三方服务。

服务1..服务N -> 通知系统 -> 第三方服务 -> 用户

引入消息队列来解耦系统组件，加入更多通知服务器并设置自动横向扩展

在分布式环境中设计通知系统时，必须考虑到可靠性问题

如何防止数据丢失？接受者会只收到一次通知吗？

通知系统最重要的需求之一是不能丢数据。通知可以延迟或者重新排序，但是不能丢。为了满足这个需求，通知系统在数据库中持久化通知数据并实现了重试机制。通知日志数据库被用来实现数据待久化。

尽管在大部分情况下通知都只会被发送一次，但分布式的性质导致可能出现重复的通知。为了减少通知的重复发送，我们引入了去重 ( dedupe ) 机制，并小心地处理每一个故障场景。

当通知事件第一次到达时，通过检查事件ID来判断它之前有没有出现过，如果之前出现过就丢弃它，否则会发出通知。