标签：规范 交流 事件驱动 The 计划 客户体验 要求 video 部分
原文 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
Re-Architecting the Video Gatekeeper(一)
标签：规范 交流 事件驱动 The 计划 客户体验 要求 video 部分
原文地址：https://www.cnblogs.com/zhukunrong/p/11337283.html
