原文: https://medium.com/netflix-te…

想法

我们决定部署一个全高密度近场缓存 (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