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

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

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

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

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

在 Instagram 上，Agoda 发布了关于他们的 Kafka 基础设施每天处理超过 3 万亿条记录的内容，并指出：“为了在数据中心中断期间保持业务连续性，我们必须能够在集群之间转移 Kafka 消费者。”

其他具有大规模流平台的公司以与 Agoda 的定制解决方案相似的方式解决了多数据中心 Kafka 故障转移挑战，尽管他们的实现因运营约束和优先级而异：

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

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

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

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

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