Re-Architecting the Video Gatekeeper(一)

2019-08-16 12:22:41来源:博客园 阅读 ()

新老客户大回馈,云服务器低至5折

Re-Architecting the Video Gatekeeper(一)

原文 https://medium.com/netflix-techblog/re-architecting-the-video-gatekeeper-f7b0ac2f6b00

本文介绍了了内容配置工程团队使用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


原文链接:https://www.cnblogs.com/zhukunrong/p/11337283.html
如有疑问请与原作者联系

标签:

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有

上一篇:Java学习第十三天

下一篇:Java线程间通信