# Netflix Blog- 重构视频GateKeeper
Date: 2019-07-22


      这篇文章[Re-Architecting the Video Gatekeeper](https://medium.com/netflix-techblog/re-architecting-the-video-gatekeeper-f7b0ac2f6b00)  是出自 [Netflix Technology Blog。](https://medium.com/@NetflixTechBlog)

       Netflix上的视频需要通过Title Operations 团队的策划，使其遵守的合同；字幕、配音、翻译能够提供给合适的人群；标题名称和概要可供使用和翻译；满足各个国家的成熟度等级（分级）。

        Gatekeeper是Netflix的系统， 他通过汇集多个上游系统数据， 应用一些业务逻辑，为每一个国家地区每一个视频状态的输出来完成器规定任务。GateKeeper 设置这些视频是否对用户可见。为Title Operations 指出缺少的内容， 协助其工作。

###     现存问题：

      GateKeeper是一个事件驱动的系统，上游系统每个改变都会向GateKeeper发送事件，GateKeep再通过访问每个上游服务来响应事件。可能会出现下问题：

- I/O  瓶颈
- 处理延时
- 事件丢失

    而主动扫描处理一些指定目录可以缓解这些问题， 但是增加了更多的事件。

###     解决方案：

      使用技术：**Hollow**  可以看下这篇文章使用技术  [Hollow](https://medium.com/netflix-techblog/netflixoss-announcing-hollow-5f710eefca4b) ( [_Drew Koszewnik_](https://www.linkedin.com/in/koszewnik?source=post_page---------------------------))，（ 2016年，是这篇的作者）

      Netflix Hollow是一个java库和工具集，用于将内存数据集从单个生产者传播到许多消费者，以实现高性能的只读访问。 适合小到中级数据集  [Hollow](http://hollow.how/?source=post_page---------------------------)

#####      第一阶段：

     使用Hollow为每个上游系统在GateKeeper增加缓存， 在指定周期内循环迭代处理所有国家地区的视频，并生成完整输出。

#####      第二阶段：

      由于第一个阶段时间片相对较长， 整个数据来自实际数据源，一个迭代周期需要很长时间。需要进一步优化。

     将Hollow分为更小时间片单位， 应用程序将每次的更改通过kafka推送 Hollow，辅助周期性的整个数据源扫描来防止数据遗漏。

###   效果：

    性能及可用性提高：消除了I/O瓶颈，提高了性能，单个上游系统故障下可以通过过时数据进行评估。

    对于新投产版本，将某一个时间X的数据做为输入， 将其输出结果其与生产版本应用的输出结果进行对比（[_diffed_](https://hollow.how/tooling/?source=post_page---------------------------#diff-tool) ）来准确判断是否达到预期效果。对于开发，验证，部署都比之前有了很大提高， 安全性方面也比以前架构更高。

    在文末也写道将在未来几个季度实现这一目标。

    对于文中描述的实时推送，全量补齐方式，实施的项目中也使用过，不过是联机+批量模式：报文从一个系统A实时推送到系统B， 夜间再通过下发批量进行全量更新补全推送时丢失的信息。

     对于数据重放到预发布版本，与生产版本比较执行执行结果， 来验证新版本是否达到预期效果，和我现在项目中验证方式不一样， 目前投产后通过实际交易进行验证， 如果能方便将相关数据重放到新版本进行验证，确实将减少不少验证的工作， 不过也需要相应的应用做出相关的改造才可以。