作者：Ankush Gulati, David Gevorkyan
贡献：Michael Clark, Gokhan Ozer翻译：欧阳锦校对：张睿毅
本文约3700字，建议阅读10 分钟本文简单介绍了Netflix构建的快速事件通知系统 (Rapid Event Notification System, RENO)，包括该系统的基本架构和优点等。介绍
Netflix 拥有超过 2.2 亿活跃会员，他们会使用各种功能执行大量操作，从个人资料重命名到影片标题搜索。确保最佳会员体验这件事上，这件事至关重要：接近实时的，响应大量的操作，以保持跨设备的体验一致性。但有件不容易的事，就是支持繁多的设备种类和大量的会员操作。为这件事，我们开发了一个快速事件通知系统（Rapid Event Notification System, RENO）以支持各种用例，并满足这些用例的可量变（scalable）和可延展（extensible）需求，使服务器能够与大量设备发起通话。
在这篇博文中，我们将概述Netflix的快速事件通知系统，并分享我们在此过程中获得的一些经验。
动机
随着会员群的快速增长和系统的日益复杂，Netflix 的架构已经演变成一种可以同时支持在线和离线计算的异步架构。提供无缝且一致的 Netflix 体验，在各种平台（iOS、Android、智能电视、Roku、Amazon FireStick、网络浏览器）和各种设备类型（手机、平板电脑、电视、计算机、机顶盒）上，不仅需要传统request - response 模型。随着时间的推移，我们看到：后端系统需要启动与设备的通信，以通知其他更新。
用例
- 查看活动
当会员开始观看节目时，其他所有设备的观看情况上，要响应更新他们的“继续观看”列表。
- 个性化体验刷新
Netflix推荐引擎不断为每个成员刷新推荐。为获得最佳的会员体验，更新需要及时传送到设备上。
- 会员计划变更
因为会员们经常改变他们的计划类型，导致必须立即反映在他们的所有设备上，当他们的体验发生变化时。
- 会员“我的清单”更新
当会员们更新他们的“我的列表”时，可能添加或删除了数个标题。此改动应在他们所有的设备上响应。
- 会员资料变更
当会员们更新自己的设置时（例如，添加/删除/重命名个人页面），或当会员们更改他们对于内容的偏好度级别时，此类更新必须同步到他们自己的所有设备上。
- 系统诊断信号
在很多特殊情况下，我们需要发送诊断信号到装有Netflix App的各种设备上，从而，帮助排查这些设备上的问题，并使这些设备能够跟踪问题。
设计决策
在设计系统时，我们做出了几个关键决策，从而搭起了RENO的架构：
1. 事件源单一化
2. 事件排序化
3. 通信模型混合
4. 交付定向化
5. 高 RPS管理
1. 事件源单一化
因为各种内部的系统和各种会员操作中，都会产生我们想要提供支持的用例。因此来自不同微服务的各种事件，我们都会需要监听。在Netflix，我们的接近实时事件流，长期在一个内部分布式计算框架中，叫曼哈顿，进行管理（您可以在https://netflixtechblog.com/system-architectures-for-personalization-and-recommendation-e081aa94b5d8 了解更多）。我们会去权衡曼哈顿的事件管理框架，在中间形成一个“中转环”，以此作为RENO中事件的单一源。
2. 事件排序化
考虑到用例在来源上和重要性上都有非常大的波动，因此，我们在事件处理中构建了细分。例如，一个会员触发事件，诸如“更改个人信息中的成熟度级别”，和诸如“系统诊断信号”这样的会员触发事件相比，要有高很多的执行优先级。我们据此为每个用例都分配一个优先级，并进行事件分区。分区是通过把事件运输任务转接到相关优先级的队列中，和相应的事件处理区中。这种分割，使我们能够在调整系统配置和扩展策略上，具有针对不同的事件优先级和运输任务模式的独立性。
3. 通信模型混合
前文提到，像RENO这样的服务，面临一个关键挑战：支持多个平台。虽然移动设备几乎总是在线，但智能电视仅在使用时才在线。这种网络连接的异质性使得，选择单一交付模式的难度增加了。举个例子，在一个拉取（Pull）模块上完全形成依赖，导致了该设备为更新而频繁往回调用，这就将导致所有的移动应用都发出大量信息。最终，会触发针对每个应用程序的通信限制，这是iOS和Android平台强制执行的（低带宽连接的问题上，我们必须要保持容忍）。但另一方面，只用一个推（Push）模块，所有的智能电视将会丢失通知信息，因为在一天中大部分时间他们处于关机状态。因此，我们选择了混合推送（Push）和拉取（Pull）的通信模型，这样，服务器会尝试使用推送通知，几乎是立即地传递到所有设备上；而所有设备会在应用周期的各阶段，去回调服务端。
使用Push-and-Pull交付模型组合同时也支持仅限于单一通信模型的设备。这其中包括了各种老旧设备，它们不支持通知推送。
4. 交付定向化
考虑到我们需要支持很多种源设备和目标设备，我们也构建了对设备特定通知的支持。此功能允许根据用例通知特定的设备类别。当可操作的事件到达时，RENO 应用特定于用例的业务逻辑，收集有资格接收此通知的设备列表并尝试进行通知。这有助于大大限制传出流量。
5. 高 RPS管理
Netflix拥有超过 2.2 亿会员，我们意识到像 RENO 这样的服务需要在观看期间处理许多事件。在高峰期，RENO每秒处理大约15万个事件。在一天中的特定时间如此高的RPS(requests per second, RPS)可能会造成惊群效应(https://en.wikipedia.org/wiki/Thundering_herd_problem)，并对内部和外部下游服务造成压力。因此，我们实施了一些优化：
- 事件年龄
许多需要通知设备的事件都是时间敏感的，如果不能立即发送，那么用户即使收到该通知，也没啥价值了。因此，应用过期过滤器作为检查门控，来避免处理过期事件。如果事件年龄超过可配置阈值，则不会对其进行处理。此过滤器会在前期处理阶段的清除对设备没有价值的事件，并防止队列因可能已过期的上游事件而被淹没。
- 在线设备
为了减少持续的流量足迹，通知仅发送到当前在线的设备，方法是利用Zuul保持最新的现有注册表（在 https://netflixtechblog.com/tagged/zuul 了解更多信息）。
- 增量策略
为了解决惊群效应并将延迟保持在可接受的阈值以下，相比缩容策略我们使用了更积极的集群扩容策略。这种方法使计算能力随着队列增长而增长。
- 事件去重
iOS 和 Android 平台都积极限制后台应用程序生成的活动级别，这就是在RENO中对传入事件进行重复数据删除的原因。RENO在高RPS的情况下可能会发生重复事件，并在不会导致设备上下文丢失的情况下，将它们合并在一起。
- 散装交付
多个下游服务用于将推送通知发送到不同的设备平台，包括用于Apple设备的Apple Push Notification Service (APNS)和用于Android的Google Firebase Cloud Messaging (FCM)等外部平台。为了防止下游服务导致整个通知服务中断，事件交付在不同平台上并行进行，这使得每个平台都尽最大努力。如果下游服务或平台未能传递通知，不会阻止其他设备接收推送通知。
架构
如上图所示，RENO 服务可以分解为以下组件：
- 事件触发器
需要刷新会员设备体验的会员操作和系统驱动更新。
- 事件管理引擎
Netflix被称为曼哈顿的近实时事件流管理框架可以配置为侦听特定事件，并将事件转发到不同的队列。
- 基于事件优先级的队列
由基于优先级的事件转发规则的Amazon SQS队列被设置在曼哈顿框架上，以允许基于优先级的流量分片。
- 基于事件优先级的集群
订阅具有相同优先级的相应队列的AWS实例集群。它们处理到达这些队列的所有事件并为设备生成可操作的通知。
- 出站消息系统
向会员发送应用内推送通知的Netflix消息系统用于将RENO在最后一英里产生的通知发送到移动设备。此消息系统在此博客文章中(https://netflixtechblog.com/building-a-cross-platform-in-app-messaging-orchestration-service-86ba614f92d8)进行了描述。
对于网络、电视和其他流媒体设备的通知，我们使用了一种名为Zuul Push的本土推送通知解决方案，它提供与在线设备的“始终在线”持久连接。要了解有关Zuul Push解决方案的更多信息，请收听Netflix同事的演讲(https://qconnewyork.com/ny2018/presentation/architectures-youve-always-wondered-about-presentation)。
- 持久存储
一个Cassandra数据库，存储了RENO为每个设备发出的所有通知，以允许这些设备以自己的节奏轮询消息。
可观察性
在Netflix，我们非常重视在我们的系统中构建强大的监控，以提供系统健康状况的清晰视图。对于像RENO这样的高RPS服务，它依赖多个上游系统作为其流量源，同时为不同的内部和外部下游系统产生大量流量，重要的是要有一个强大的指标组合、警报和日志记录。对于警报，除了 CPU、内存和性能等标准系统健康指标外，我们还添加了许多“服务边缘”指标和日志记录，以捕获上游或下游系统的任何异常。
此外，除了实时警报之外，我们还为重要指标添加了趋势分析，以帮助捕捉长期退化。我们使用名为Mantis的实时流处理应用程序来检测RENO（您可以在此处了解更多信息）。它使我们能够以设备特定的粒度实时跟踪事件，从而使调试更容易。最后，我们发现拥有特定于平台的警报（适用于 iOS、Android 等）有助于更快地找到问题的根本原因。
优点
- 可以轻松支持新用例
- 以更高的吞吐量水平扩展
当我们着手构建 RENO 时，该系统的目标仅限于产品端的“个性化体验刷新”这一用例。随着 RENO 的发展，对新用例的支持成为可能，RENO 很快被定位为 Netflix 所有产品领域的集中化快速通知服务。
我们早期做出的设计决策，例如，决定新用例成为“即插即用”解决方案的增加服务，及跨平台混合交付模型的提供，都得到了回报。我们让和外的产品使用案例快速上线，从而让大量创新畅通无阻。
构建这个平台的一个重要经验是确保随着时间的推移需要更多类型的事件和更高的吞吐量，RENO 可以水平扩展。这种能力主要是通过允许基于事件类型或优先级的分片以及使用异步事件驱动的处理模型来实现的，该模型可以通过添加更多机器进行事件处理来扩展系统。
未来展望
Netflix会员群体的持续性快速增长下，拥有像RENO这样的服务可以帮助我们的会员获得最好和最新的Netflix体验。从会员相关的更新，到基于场景的个性化，我们没有停止——我们正持续开发我们的推送套餐，同时，为了会员体验，不断创新。架构方面，我们一直在关注增加更多功能的时机，比如消息传递的保障服务，比如消息批处理。这些功能会开展更多用例，并能减少RENO的通信留存。
加入我们，一起创造伟大
我们刚刚开始构建有影响力的系统，帮助推动我们的业务向前发展。我们与同事的直接合作，并使用最有影响力的工具和技术是将这些工程解决方案变为现实的核心。如果这让您感到兴奋，我们希望您能加入我们(https://jobs.netflix.com/)。
原文标题：
Rapid Event Notification System at Netflix
原文链接：
https://netflixtechblog.com/rapid-event-notification-system-at-netflix-6deb1d2b57d1
编辑：黄继彦
校对：林亦霖
译者简介
欧阳锦，一名在埃因霍温理工大学就读的硕士生。喜欢数据科学和人工智能相关方向。欢迎不同观点和想法的交流与碰撞，对未知充满好奇，对热爱充满坚持。
翻译组招募信息
工作内容：需要一颗细致的心，将选取好的外文文章翻译成流畅的中文。如果你是数据科学/统计学/计算机类的留学生，或在海外从事相关工作，或对自己外语水平有信心的朋友欢迎加入翻译小组。
你能得到：定期的翻译培训提高志愿者的翻译水平，提高对于数据科学前沿的认知，海外的朋友可以和国内技术应用发展保持联系，THU数据派产学研的背景为志愿者带来好的发展机遇。
其他福利：来自于名企的数据科学工作者，北大清华以及海外等名校学生他们都将成为你在翻译小组的伙伴。
点击文末“阅读原文”加入数据派团队~
转载须知
如需转载，请在开篇显著位置注明作者和出处（转自：数据派ID：DatapiTHU），并在文章结尾放置数据派醒目二维码。有原创标识文章，请发送【文章名称-待授权公众号名称及ID】至联系邮箱，申请白名单授权并按要求编辑。
发布后请将链接反馈至联系邮箱（见下方）。未经许可的转载以及改编者，我们将依法追究其法律责任。
点击“阅读原文”拥抱组织
