Re-Architecting the Video Gatekeeper(二)

原文: https://medium.com/netflix-te...

想法

咱们决定部署一个全高密度近场缓存(Hollow)来解决咱们的IO瓶颈。对于咱们的每一个上游系统，咱们要建一个能让Gatekeeper执行此次评估的包括全部数据的Hollow数据集。每一个上游系统如今都须要保证它的缓存保持最新。

使用这个模型，活跃性评估将数据从上游系统中隔离出来了。相对于对事件进行响应，Gatekeeper会以一个重复的周期从遍及全世界的视频数据中持续的处理活跃性数据。迭代周期从Netflix的每一个视频上线开始，计算它们的活跃性信息。在每一个周期的结束，它产出一个通过计算的表示全世界全部视频的活跃性明细信息的输出(包括Hollow数据集)。

咱们但愿这个持续处理模型是可行的，这样咱们能够完全移除咱们IO上的瓶颈，能够保证操做顺序更有效。咱们也指望经过迁移到这个模型，咱们能够对业务产生更正面的影响。

• 做为对Gatekeeper对上游系统产生的过大的负载的最终解决方案
• 完全消除活跃性处理的延迟和错过上线日期的问题。
• 缓解内容配置工程团队在性能相关问题的时间消耗。
• 改进活跃性处理的可调试性和可见性

问题

Hollow能够被想象为一个时间机器。做为一个数据一直在变化的数据集，经过将变动分红一系列的时间线的数据状态并将变动发送给消费方。每份数据状态都表示为整个数据集在当时时刻的一份快照。

一般，Hollow数据集的消费者将加载的最新的数据状态并将产生的新状态保存到他们的混存中。固然，它们可能会将状态替换到以前的样子 - 致使将整个数据集指向以前的一个状态。

传统产生数据状态的方式是维护一个运行重复周期的生产者。在一个周期中，生产者从元数据中迭代全部记录。在迭代中，它对Hollow库中增长每条数据。Hollow则在以后计算数据的变化并在最后的周期将数据填加上去，将数据状态发布到一个已知地址的消费者。

这个基于真实数据源的迭代模型的问题是它可能会须要很长时间。在这个场景中一些咱们的上游系统，这须要几小时。数据传播延迟是不可接受的 - 咱们不能为活跃性处理等待几个小时，好比，标题运营给电影增长了一个评级并须要当即发布上线。

改进

咱们须要一个更快的时间机器 - 它能够更频繁的产出状态，让消费方能够更快的识别到变化。

为了达到这个目标，咱们创建了一套很强的Hollow基础设施，平衡了以前Hollow library作的工做，与流处理团队在Target生产环境作的先锋性工做(如今是公开的非beta的API)

使用这套基础设施，每次变动均可以在源应用中呗检测到，更新过的记录会被编码并发送给Kafka topic。一个不属于源应用的新组件，Hollow增量生产服务，以一个预约义的节奏执行一个重复周期。 在每一个周期，它读取自从上个周期全部增长到topic的消息，并让Hollow状态引擎反映出更新过的记录的最新状态。

若是一个Kafka topic中的消息包含了已经在Hollow数据集中已经反映出来的相同数据，不会有任何变更。

为了缓解丢失事件产生的影响，咱们实现了一套周期性从整个数据集清扫的机制。当它执行时，它将每条记录的内容发送给Kafka topic。经过这种方式，任何可能丢失的更新都会反映到Hollow数据集上。而且，这不是更新传播到Hollow数据集上的主要方式，它不须要像传统Hollow使用方式那样很快很频繁的在源上迭代运行。

Hollow增量生产者有从Kafka topic中读取大量消息并快速转变成Hollow状态的能力 - 因此咱们能够将这个周期配置的很是短(咱们目前的缺省配置是30秒)。

这就是咱们如何构建一个更快时间机器的方式。如今，若是标题运营给电影增长了一条评级，在30秒内，数据就能够在Hollow数据集上可用。

—

本文来自微信公众号「麦芽面包，id「darkjune_think」转载请注明。微信扫一扫关注公众号。交流Email: zhukunrong@yeah.net