Agoda 通过自定义的双向同步功能来处理跨数据中心的 Kafka 消费者故障转移

Agoda 的工程团队最近分享了他们定制的解决方案，该方案旨在跨多个内部数据中心维护关键的 Kafka 消费者操作，确保即使在中断期间也能保持业务连续性。Agoda 每天处理超过 3 万亿条 Kafka 记录，需要一种故障转移机制，可以无缝地在不同的Kafka集群之间转移消费者工作负载，同时保留处理状态，避免数据重复或丢失。

Agoda 的工程师没有依赖于 Kafka 的扩展集群，这由于地理延迟而不切实际，也没有依赖于缺乏双向偏移同步的MirrorMaker 2，而是开发了一个增强系统，扩展了 MirrorMaker 2 以支持可靠的故障转移、无缝的故障恢复和持久的偏移转换。他们的方法涉及在集群之间始终开启消费者组偏移和OffsetSync记录的双向同步。当消费者组在一个数据中心提交偏移时，该偏移量会在另一个集群中使用围绕Kafka Connect和 OffsetSync 机制构建的自定义同步服务进行转换和更新。

在故障转移场景中，由于转换和复制的偏移，辅助集群能够从原始位置消费的确切点接管处理。当主数据中心恢复时，系统支持故障恢复：消费者偏移同步回原始集群，确保连续性，不会重复消息或丢失进度。为了避免循环偏移更新，同步服务在应用更新之前检查已经同步的状态。

该系统还包括强大的可观测性组件：专用的 Grafana 仪表板跟踪诸如复制延迟、同步失败和消费者滞后等指标，以便及早发现异常并在操作影响发生之前进行干预。这种实时的可见性支持跨多个数据中心的 Kafka 部署的可靠性。

定制的故障转移和故障恢复架构反映了一个日益增长的趋势，即在多数据中心规模上进行工程的组织不能依赖于 Kafka 的默认功能。根据 Agoda 的说法，这个系统为服务连续性、精确的处理语义和大规模的灾难恢复能力提供了必要的弹性。这种方法突出了对运维严谨性和设计灵活性的战略承诺，使 Agoda 的数据平台能够在不妥协正确性或吞吐量的情况下承受基础设施中断。

在 Instagram 上， Agoda发布了他们的 Kafka 基础设施每天处理超过 3 万亿记录的帖子，并指出：

“为了在数据中心中断期间保持业务连续性，我们必须能够跨集群转移 Kafka 消费者。”

其他拥有大规模流式平台的公司已经以与 Agoda 的自定义解决方案相似的方式解决了多数据中心 Kafka 故障转移的挑战，尽管它们的实现因运维约束和优先事项而异。

MirrorMaker 2 是 Kafka 内置的跨集群复制工具。默认情况下，它支持单向复制，将数据从主集群复制到备集群。虽然这适用于主动-被动故障转移场景，但它缺乏对双向偏移同步和无缝故障恢复的原生支持。如果没有自定义扩展，MM2 无法在镜像主题之间转换消费者偏移，这意味着消费者将不得不重新处理消息，或在故障转移后面临数据丢失的风险。

Netflix在 Kafka 上运行多区域 active-active 系统，用于事件和微服务通信。他们的解决方案利用了基于 MirrorMaker（pre-MM2）上的自定义工具来在区域之间复制数据。对于故障转移，Netflix 集成了它的控制平面（Zuul、Eureka），以重定向流量并在其他区域恢复消费者。虽然 Agoda 的解决方案自动化了偏移转换，但 Netflix 历来优先考虑幂等事件处理和重放，以处理故障恢复场景。

Uber的流式堆栈（uChannel，Apache Kafka）支持像 Uber 外卖和乘车调度这样的全球服务。他们实施了地理分布式复制，但通常依赖于异步故障转移模型。与 Agoda 类似，Uber 避免跨区域同步集群，并使用本地偏移与检查点来在灾难恢复场景中恢复消费。他们的模型强调按地理位置划分工作负载，并在故障恢复期间从检查点重放，而不是持续的双向同步。

Confluent 的商业工具扩展了MM2，提供了更高级的功能，如更好的主题自动创建和模式复制。然而，与 MM2 类似，它本身并没有解决双向故障转移的偏移转换问题。此外，企业在采用 Confluent 的解决方案时可能会面临供应商锁定和许可成本。

Agoda 的设计需要持续的偏移同步和可观测性工具（用于同步延迟和失败率的 Grafana 仪表盘）。与简单的单向容灾设置相比，这增加了复杂性，但为关键的高容量工作负载提供了更高的可靠性和正确性。其他优先考虑成本和简单性的公司可能会接受一些重放或手动故障恢复，而不是构建自定义解决方案。

原文链接：

https://www.infoq.com/news/2025/08/agoda-kafka-failover/