Re-Architecting the Video Gatekeeper(一)

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

本文介绍了了内容配置工程团队使用Hollow，一个Netflix OSS技术，从新架构与简化咱们内容管道上的基础组件 - 在流程中交付巨大业务价值。

上下文

每一个在Netflix服务上的电影和秀都被精心处理以提供最佳的观看体验。团队对处理主要负责标题运营(Title Operation)。标题运营会确认，除了：

• 咱们确保合同符合规范 - 咱们为每一个标题配置的视频日期时间段与位置是正确的。
• 视频的标题，字幕，第二音轨都被翻译并被正确分发到世界各地。
• 标题名与概要均可用并被翻译。
• 每一个国家都有合适的观影等级

当标题达到了以上需求的最低要求，它就能够发布到服务上上线。Gatekeeper是在Netflix负责评估网站上视频和资产的“活跃度”。在Gatekeeper批准前标题对于会员是不可见的 - 若是它验证不了设置，它会指出从客户体验基线上缺了什么来辅助标题运营(Title Operation)。

Gatekeeper经过聚合多个上游系统的数据来完成预处理任务，使用合适的业务逻辑，生产和输出每一个国家每一个视频的详细状态。

技术

Hollow, 是咱们几年前发布的OSS技术。并被描述为一种靠近缓存的全高密度(total high-density near cache)技术：

• 全：在每一个节点上都缓存着这个数据集 - 没有驱逐策略，没有缓存命中丢失。
• 高密度：编码，解码，反重复技术都被用来数据集上的内存指纹。
• 靠近：在每一个须要存取数据集的实例上都有RAM上的缓存。

对于这个全(total)技术有一个使人兴奋的内容 - 由于咱们不须要担忧清除内存中的数据项，咱们能够对内存中的数据集展现作一些假设与预计算，没有这个特性是不可能的。结果是，对许多数据集，提升了很大的内存使用效率。而在传统的部分缓存方案上你可能会想是否你只缓存了5%的数据集，或者你须要被10%保留足够的空间用来获得一个可接受的命中/丢失率 - 使用一样的内存Hollow能够缓存100%的数据集数据并获得100%的命中率。

很明显，若是你有100%的命中率，你能够消除全部访问你数据的IO需求 - 并能够更有效的提升数据访问效率，能够开启更多可能性。

现状

在不久之前，Gatekeeper是一个彻底的事件驱动系统。当任何上游系统对视频有改动，系统会发送给Gatekeeper发送一个事件。Gatekeeper会对那条事件进行响应，进入每个它的上游服务，收集必要的输入数据来评估视频与它的对应资产的活跃性。它会产生一条输出记录来输出这条视频的详细状态。

这个模型有一些相关的问题：

• 这个进程彻底与IO绑定，并对上游系统产生了很大的负载。
• 所以，这些事件会将一天的吞吐队列化并产生处理的延迟，致使标题的处理不能及时的上线。
• 更坏的，事件可能偶尔丢失，这将致使标题不能上线，知道某一个标题运营人员发现可能有问题。

为了减轻这些问题能够“清扫”目录让视频能够匹配特定的查询条件(好比，计划下周上线)可让事件自动注入处处理队列中。不幸的是，这种方式会往队列中增长更多的事件，会使问题更加恶化。

很明显，颇有必要改变方向。

---

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