面试场景题系列：设计通知系统

近几年，通知系统(Notification System)已成为许多应用中的一个非常受欢迎的功能。通知系统可以向用户发送一些重要信息，比如突发新闻、产品更新、活动和商品优惠信息等。它已经成为人们日常生活中不可或缺的一部分。在本章，你被要求设计一个通知系统。这里所说的通知不仅仅指手机推送的通知。有3种类型的通知：手机推送通知、短信和邮件。图-1展示了这些通知的例子。

图-1

1. 确定设计的边界

构建一个每天发送数百万次通知的可扩展的系统并非易事。这要求设计者对通知生态系统有深入的理解。面试问题会被有意设计成开放式的和模糊的，你必须通过提问来厘清需求。

**候选人：**系统支持什么类型的通知？

**面试官：**手机推送通知、短信和邮件。

**候选人：**它是一个实时系统吗？

**面试官：**可以说它是一个软实时系统。我们希望用户尽可能早地收到通知。但是如果系统的负载很高，可以接受短暂的延时。

**候选人：**需要支持哪些设备？

**面试官：**iOS设备、安卓设备和笔记本电脑/台式机。

**候选人：**由什么触发通知？

**面试官：**通知可以被客户端应用触发，也可以在服务器端定时触发。

**候选人：**用户可以取消通知吗？

**面试官：**是的，取消后用户将不再收到通知。

**候选人：**每天发送多少通知。

**面试官：**1000万条手机推送通知、100万条短信和500万封邮件。

2.顶层设计

本节会展示支持各种通知类型的高层级设计，包括：iOS推送通知、安卓推送通知、短信和邮件。本节内容的结构如下：

•不同类型的通知。

•联系信息的收集流程。

•通知的发送/接收流程。

2.1 不同类型的通知

我们先在高层级来看每个类型的通知是怎么工作的。

iOS推送通知

发送iOS推送通知，主要需要3个组件，如图-2所示。

图-2

•服务商(Provider)。服务商构建通知，然后将其发送到APNS（Apple Push Notification Service，苹果推送通知服务）。为了构建一个推送通知，服务商会提供如下数据。

◆ 设备令牌(Token)：这是用来发送推送通知的唯一标识。

◆ 载荷(Payload)：这是一个包含通知内容的JSON字典。下面是一个例子。

{
  "aps":{
      "alerts":{
        "title":"Game Request"
        "body":"Bob wants to play chess"
        "action-loc-key":"PLAY"
      },
    "badge":5
  }
}

•APNS：这是苹果公司提供的一项远程服务，用来将推送通知传输到iOS设备上。

•iOS设备：它是终端客户端，用于接收推送通知。

安卓推送通知

安卓系统采用了类似的通知流程，如图-3所示。与使用APNS不同，安卓系统通常使用FCM(Firebase Cloud Messaging)给安卓设备推送通知。

图-3

短信谈到短信，许多开发者和企业常常使用第三方短信服务。它们中的大多数都是商业服务。图-4所示为短信的推送流程。

图-4

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

图-5

图-6展示了加入所有第三方服务之后的设计。

图-6

2.2 联系信息的收集流程

为了发送通知，我们需要收集移动设备的令牌、手机号或者邮箱信息。如图-7所示，当用户安装我们的应用或者第一次注册时，API服务器会收集用户的联系信息并把它存储在数据库中。

图-7

图-8展示了简化的存储用户联系信息的数据库表。邮箱地址和手机号存储在用户表(user)中，而对应的设备令牌存储在设备表(device)中。一个用户可以拥有多个设备，意味着可以将一个推送通知发送到用户所有的设备上。

图-8

2.3 通知的发送与接收流程

我们先展示初步设计，然后再提出一些优化方案。

高层级设计

图-9展示了总体设计。接下来，我们对每个系统组件进行解释。

**服务1到服务N：**这里的服务可以是微服务、定时任务，也可以是触发通知发送事件的分布式系统。例如，账单服务发送邮件提醒用户付款，或者购物网站通过短信告诉用户其包裹会在明天送达。

**通知系统：**该系统是发送/接收通知的核心组件。我们从简单的开始，只使用一个通知服务器，它为服务1到服务N提供API，并且为第三方服务构建通知载荷。

第**三方服务：**第三方服务负责发送通知给用户。集成第三方服务时，我们需要格外注意可扩展性。具有高可扩展性意味着系统很灵活，可以轻松插入或者移除第三方服务。另一个需要考虑的要点是，第三方服务有可能在新市场或者未来不可用。比如，FCM在中国大陆就是不可用的，因此在中国大陆需要使用替代的第三方服务，比如Jpush、PushY等。

**iOS推送通知、安卓推送通知、短信、邮件：**这些是用户在其设备上收到的通知。

图-9

在这个设计中，我们可以发现以下3个问题。

•单点故障(SPOF)：单台通知服务器就意味着存在SPOF。

•很难扩展：通知系统在一台服务器上处理关于推送通知的所有事情，因此要独立地扩展数据库、缓存和不同的通知处理组件将很有挑战性。

•性能瓶颈：处理和发送通知可能会消耗大量资源。比如，构建HTML页面和等待第三方服务的响应可能会花较长时间。在一个系统中处理所有事情可能会导致系统过载，特别是在流量高峰时段。

改进后的高层级设计

针对上述问题，我们对初始设计按如下方式改进：

•把数据库和缓存从通知服务器中移出。

•加入更多的通知服务器并设置自动横向扩展。

•引入消息队列来解耦系统组件。

图-10展示了改进后的高层级设计。

图-10

我们按照从左到右的顺序来解释图-10中的组件。

**服务1到服务N：**这些不同的服务通过调用通知服务器提供的API来发送通知。

通知服务器：通知服务器提供了如下的功能。

•为服务提供API来发通知。这些API只能在内部或者由验证过的客户端访问，以避免被滥用来发送垃圾信息。

•实施基本的身份校验，需要验证邮箱地址、电话号码等。

•查询数据库或者缓存来获取渲染通知所需的数据。

•把通知数据放到消息队列中做并行处理。

**缓存(Cache)：**缓存用户信息、设备信息和通知模板。

**数据库：**存储关于用户、通知、设置等的数据。

**消息队列：**消息队列解决了组件间的依赖问题。当大量的通知被发出时，消息队列用作缓冲区。每种类型的通知都有特定的消息队列，因此一个第三方服务出现故障并不会影响其他类型的通知。

**Worker：**Worker是一组服务器，它们从消息队列中拉取通知事件并将其发送给对应的第三方服务。

**iOS推送通知、安卓推送通知、短信、邮件：**在初始设计中已经讲过了。

接下来，让我们看看每个组件是如何协同工作来发送通知的。

1.服务调用通知服务器提供的API来发送通知。

2.通知服务器从缓存或者数据库中获取用户信息、设备令牌和通知设置等元数据。

3.通知事件被发送到对应的队列中处理。比如，一个iOS推送通知事件被发送到iOS消息队列。

4.Worker从消息队列中拉取通知事件。

5.Worker将通知发送给第三方服务。

6.第三方服务将通知发送到用户的设备上。

3.设计继续深入

在第2节，我们讨论过不同类型的通知、联系信息的收集流程和通知的发送/接收流程。接下来，我们会深入探索以下内容。

•可靠性。•

其他组件和考虑因素：通知模板、通知设置、流量限制、重试机制、推送通知中的安全问题、监控队列中的通知和事件追踪。

•更新后的设计。

3.1 可靠性

在分布式环境中设计通知系统时，我们必须回答一些重要的可靠性问题。

如何防止数据丢失？

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

图-11

接收者会只收到一次通知吗？

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

当通知事件第一次到达时，我们通过检查事件ID来判断它之前有没有出现过。如果之前出现过，就丢弃它，否则我们会发出通知。想探寻为什么无法确保一条通知只发送一次的读者，可以看一下网站bravenewgeek上的文章“You Cannot Have Exactly-Once Delivery”。

3.2 其他组件和要考虑的因素

我们已经讨论了如何收集用户联系信息、发送和接收通知，但通知系统的内容远不止于此。本节讨论其他组件，包括通知模板、通知设置、事件追踪、系统监控、流量限制等。

通知模板

一个大型通知系统每天会发送数百万条通知，其中有很多都遵循类似的格式。为了避免每次都从头开始构建通知，可以采用通知模板。通知模板是一个预先定好格式的通知，你可以通过自定义参数、样式、追踪链接等来创建独特的通知。以下是一个推送通知模板的示例。

使用通知模板能保持通知的格式一致和节省时间。

通知设置

通常，用户每天会收到很多通知，很容易感到不知所措。因此，很多网站和应用允许用户对通知进行精细的控制。这些设置信息存储在通知设置表里，这个表包含如下字段：

在向用户发送任何通知之前，我们应该先检查用户是否同意接收这种类型的通知。

流量限制

为了避免用太多的通知“轰炸”用户，我们可以限制用户能收到的通知的数量。这一点很重要，因为如果通知发送得太频繁，接收者可能会完全关闭通知。

重试机制

如果第三方服务在发送通知时失败，该通知会被加入消息队列以便重新发送。如果这样的问题持续发生，就会给开发人员发送告警信息。

推送通知的安全问题

对iOS应用或者安卓应用，appKey和appSecret被用来确保推送通知API的安全。只有验证过身份或者经过检验的客户端才能使用我们的API来发送推送通知。感兴趣的读者可以阅读相关参考资料。

监控队列中的通知

队列中的通知总数是要监控的一个关键指标。如果这个数量很大，说明Worker对通知事件的处理速度不够快。为了避免通知被延迟发送，需要更多的Worker。图-12展示了队列中需要处理的消息数随时间的变化情况。

图-12

事件追踪

通知系统的指标，比如打开率、点击率和参与度，对理解用户行为来说非常重要。数据分析服务实现了事件追踪。通知系统和数据分析服务通常是需要集成的。图-13中列出了一些可以被跟踪和记录的用于数据分析的事件示例。

图-13

3.3 更新后的设计

把所有的组件整合在一起，图-14展示了更新后的通知系统。

图-14

相比之前的设计，这一版添加了很多新组件。

•通知服务器配备了两个新的重要功能：身份验证和流量限制。

•我们添加了重试机制来应对通知发送失败。如果系统无法发送通知，它们会被放回到消息队列中，Worker会按照预先设定好的次数重新尝试发送。

•此外，通知模板提供了一致且高效的通知创建流程。

•最后，为了方便进行系统健康检查和未来的优化，我们加入了监控和跟踪系统。

4.总结

通知是不可或缺的，因为它使我们及时了解重要信息，比如一条来自Netflix的关于你最喜欢的电影的通知、一封关于新产品打折的邮件，或者一条你网购后的付款确认消息。

在本章中，我们描述了一个可扩展的通知系统的设计，它支持多种类型的通知：推送通知、短信和邮件。我们采用了消息队列来解耦系统组件。

除了高层级设计，我们深入探讨了其他组件和优化方案。

•可靠性：我们提议采用健壮的重试机制来最小化故障率。

•安全性：使用appKey/appSecret对来确保只有验证过的客户端才可以发送通知。

•追踪和监控：在通知流程的任何阶段都可以实现这些功能，从而获取重要的统计数据。

•尊重用户的设置：用户可能会选择不再接收通知。我们的系统在发送通知之前要先检查用户的设置。

•流量限制：用户希望限制所收到的通知数量。