Re-Architecting the Video Gatekeeper(二)
原文: https://medium.com/netflix-techblog/re-architecting-the-video-gatekeeper-f7b0ac2f6b00
想法
我们决定部署一个全高密度近场缓存(Hollow)来解决我们的IO瓶颈。对于我们的每个上游系统，我们要建一个能让Gatekeeper执行这次评估的包括所有数据的Hollow数据集。每个上游系统现在都需要保证它的缓存保持最新。
使用这个模型，活跃性评估将数据从上游系统中隔离出来了。相对于对事件进行响应，Gatekeeper会以一个重复的周期从遍布全世界的视频数据中持续的处理活跃性数据。迭代周期从Netflix的每个视频上线开始，计算它们的活跃性信息。在每个周期的结束，它产出一个经过计算的表示全世界所有视频的活跃性明细信息的输出(包括Hollow数据集)。
我们希望这个持续处理模型是可行的，这样我们可以彻底移除我们IO上的瓶颈，可以保证操作顺序更有效。我们也期望通过迁移到这个模型，我们可以对业务产生更正面的影响。
- 作为对Gatekeeper对上游系统产生的过大的负载的最终解决方案
- 彻底消除活跃性处理的延迟和错过上线日期的问题。
- 缓解内容配置工程团队在性能相关问题的时间消耗。
- 改进活跃性处理的可调试性和可见性
问题
Hollow可以被想象为一个时间机器。作为一个数据一直在变化的数据集，通过将变更分成一系列的时间线的数据状态并将变更发送给消费方。每份数据状态都表示为整个数据集在当时时刻的一份快照。
通常，Hollow数据集的消费者将加载的最新的数据状态并将产生的新状态保存到他们的混存中。当然，它们可能会将状态替换到之前的样子 – 导致将整个数据集指向之前的一个状态。
传统产生数据状态的方式是维护一个运行重复周期的生产者。在一个周期中，生产者从元数据中迭代所有记录。在迭代中，它对Hollow库中增加每条数据。Hollow则在之后计算数据的变化并在最后的周期将数据填加上去，将数据状态发布到一个已知地址的消费者。
这个基于真实数据源的迭代模型的问题是它可能会需要很长时间。在这个场景中一些我们的上游系统，这需要几小时。数据传播延迟是不可接受的 – 我们不能为活跃性处理等待几个小时，比如，标题运营给电影增加了一个评级并需要立即发布上线。
改进
我们需要一个更快的时间机器 – 它可以更频繁的产出状态，让消费方可以更快的识别到变化。
为了达到这个目标，我们建立了一套很强的Hollow基础设施，平衡了之前Hollow library做的工作，与流处理团队在Target生产环境做的先锋性工作(现在是公开的非beta的API)
使用这套基础设施，每次变更都可以在源应用中呗检测到，更新过的记录会被编码并发送给Kafka topic。一个不属于源应用的新组件，Hollow增量生产服务，以一个预定义的节奏执行一个重复周期。 在每个周期，它读取自从上个周期所有增加到topic的消息，并让Hollow状态引擎反映出更新过的记录的最新状态。
如果一个Kafka topic中的消息包含了已经在Hollow数据集中已经反映出来的相同数据，不会有任何变动。
为了缓解丢失事件产生的影响，我们实现了一套周期性从整个数据集清扫的机制。当它执行时，它将每条记录的内容发送给Kafka topic。通过这种方式，任何可能丢失的更新都会反映到Hollow数据集上。并且，这不是更新传播到Hollow数据集上的主要方式，它不需要像传统Hollow使用方式那样很快很频繁的在源上迭代运行。
Hollow增量生产者有从Kafka topic中读取大量消息并快速转变成Hollow状态的能力 – 所以我们可以将这个周期配置的非常短(我们目前的缺省配置是30秒)。
这就是我们如何构建一个更快时间机器的方式。现在，如果标题运营给电影增加了一条评级，在30秒内，数据就可以在Hollow数据集上可用。
—
本文来自微信公众号「麦芽面包，id「darkjune_think」
转载请注明。微信扫一扫关注公众号。
交流Email: zhukunrong@yeah.net