ReArchitecting-the-Video-Gatekeeper一

38次阅读

共计 1361 个字符,预计需要花费 4 分钟才能阅读完成。

原文 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

正文完
 0