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
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
