多集群拓扑：为什么需要跨集群复制
单集群 Kafka 能覆盖大部分业务规模，扩容可以解决部分容量问题。但真正把架构引向多集群的，是四类无法用单集群回答的问题：
- 一个机房 / 一个 region 挂了，业务能不能继续跑？
- 跨地域访问延迟高，能否让每个 region 消费者读本地副本？
- 合规要求某类数据不能出境 / 出 region，能否只把脱敏后的数据复制到中心集群？
- 多个边缘集群产生数据，如何汇聚到中心做统计分析？
这四个问题对应四种典型拓扑。选型不当会让复制方案在故障切换时失效，直接影响恢复时间与数据一致性。
1. 四种典型拓扑
1.1 Active-Standby（灾备）
主集群承担 100% 生产流量，Standby 集群通过复制持续同步。正常情况下 Standby 只是"接盘位"，不对外提供读。当主集群不可用（机房故障、网络分区、误操作）时，业务切到 Standby。
producer consumer
│ │
▼ ▼
┌─────────────┐ MM2 ┌─────────────┐
│ Primary │─────────▶│ Standby │
│ (active) │ │ (passive) │
└─────────────┘ └─────────────┘关键决策：
- Standby 不承接业务写流量——业务应用只向主集群写入，避免脑裂后合并数据无从下手。这一约束需要通过权限、路由和切换流程落实，不能只靠应用约定。
- RPO 目标需预先定义，故障时实际可能丢失的数据取决于主集群中尚未复制到备集群的数据量。复制延迟影响丢失范围，但不能把复制延迟直接当作 RPO 目标。
- RTO（切换时间）= 检测故障 + 切流量 + consumer offset 重定位。offset 翻译是这里的技术难点，详见 §3 offset translation。
适用场景：金融、电商这类核心域。需要独立故障域、希望在主集群故障后恢复服务，且团队具备 SRE 能力、有独立灾备演练流程。是否满足数据丢失与恢复时间目标，仍需结合复制延迟、切换机制和演练结果评估。
1.2 Active-Active（双活）
两个集群同时接收生产流量，互相复制。在剩余集群具备足够容量、必要数据可用且切流机制有效的前提下，可以承接故障区域转移过来的流量。
┌─────────────┐ MM2 ┌─────────────┐
│ us-east │ ────────▶ │ us-west │
│ (active) │ ◀──────── │ (active) │
└─────────────┘ MM2 └─────────────┘
▲ ▲
│ │
east producers west producers关键决策：
- 循环防护是硬要求。
us-east的 topicorders复制到us-west后叫us-east.orders；us-west的orders复制到us-east后叫us-west.orders。MM2 默认的DefaultReplicationPolicy会为复制过来的 topic 添加源集群别名前缀，并据此识别远端 topic。双向复制时仍需结合源集群配置、topic 选择规则和命名策略验证复制路径，不能把前缀命名本身当作所有配置下的循环防护保证。 - 每个 region 的应用只写本地 topic、订阅本地 + 远端前缀 topic。跨集群复制不会自动合并两份日志，也不会为业务记录建立全局顺序；消费端按业务需求订阅本地 topic 和远端复制 topic。
- 数据一致性不是强的。两侧存在异步复制延迟，延迟大小取决于网络、源端负载和复制任务处理能力，不能预设固定上限。如果业务需要"全球唯一订单号"、"全球计数器"这类强一致语义，Active-Active 不合适。
适用场景：跨地域用户就近读写、要求任一 region 挂掉都不影响。典型如全球化的 SaaS。
1.3 Hub-and-Spoke（星型汇聚）
多个边缘集群（spoke）单向复制到一个中心集群（hub），中心做统一分析、归档、二次分发。
┌──────────┐ ┌──────────┐ ┌──────────┐
│ edge-BJ │ │ edge-SH │ │ edge-GZ │
└────┬─────┘ └────┬─────┘ └────┬─────┘
│ │ │
└────MM2──────┼───MM2───────┘
▼
┌──────────┐
│ central │
└──────────┘关键决策：
- 只从边缘复制到中心，中心不回写边缘。
- 边缘和中心可以设置不同的 topic 保留策略——边缘保留 3 天用于本地实时业务，中心保留 30 天用于分析。但需注意 MM2 的 topic 配置同步：若启用了配置同步，源端保留策略可能同步覆盖目标端，差异化保留需结合
sync.topic.configs.enabled等配置验证。中心容量预算需按所有边缘的总写入量、保留周期和副本开销计算，不能只按单个边缘集群估算。 - 若合规要求限制敏感字段跨地域传输，应在数据离开源集群前落实过滤或脱敏，并验证复制任务不会绕过这条边界；不能把"复制到中心后再脱敏"视为满足出境限制。
适用场景：IoT 数据聚合、CDN 上报、多机房日志入湖、跨国公司数据回流到总部。
1.4 Stretch Cluster（拉伸集群）
严格来说这不算"多集群"——它是把单个 Kafka 集群的 broker 部署到多个可用区（AZ），依赖 Kafka 自身的副本机制而不是 MirrorMaker 做跨区容灾。
┌─────────── Kafka Cluster ────────────┐
│ │
│ ┌───AZ1───┐ ┌───AZ2───┐ ┌───AZ3───┐│
│ │ broker1 │ │ broker2 │ │ broker3 ││
│ │ broker4 │ │ broker5 │ │ broker6 ││
│ └─────────┘ └─────────┘ └─────────┘│
└───────────────────────────────────────┘关键决策：
- 通常采用副本因子 ≥ 3、
min.insync.replicas = 2，并为 broker 配置正确的broker.rack，使副本分配考虑 AZ 故障域。部署后应检查每个分区的副本分布，确认单 AZ 故障不会同时移除该分区的全部可用副本；生产者通常还需配合acks=all落实写入确认策略（ISR 机制详见核心篇）。 - 依赖 AZ 之间稳定且低延迟的网络。跨 region 部署会显著增加副本同步与写入确认的延迟，并放大网络分区对可用性的影响，因此一般优先考虑独立集群加跨集群复制。
- Kafka 2.4 引入的 KIP-392 支持 consumer 按
client.rack就近读取副本。这需要对应版本的客户端与 broker 支持、broker 副本选择器配置正确，且目标副本可用；满足这些条件时可减轻跨 AZ 流量，但不能保证每次 fetch 都落在本地 AZ。
适用场景：同 region 内多 AZ 容灾，能容忍单 AZ 故障。
2. 四种拓扑的横向对比
| 维度 | Active-Standby | Active-Active | Hub-and-Spoke | Stretch Cluster |
|---|---|---|---|---|
| 集群数量 | 2（1 写 1 备） | 2+（都写） | N+1 | 1（跨 AZ） |
| 数据流向 | 单向 | 双向 | 边缘→中心 | 集群内部副本 |
| RPO | 取决于复制进度 | 取决于复制进度 | 取决于复制进度 | 取决于副本与确认策略 |
| RTO | 取决于检测、切流与位点恢复 | 取决于检测、切流与消费恢复 | 不适用 | 取决于故障检测、Leader 选举及客户端恢复 |
| 循环风险 | 单向复制时风险较低 | 需前缀防护并验证配置 | 单向复制时风险较低 | 不适用 |
| 一致性 | 主-备异步复制 | 两侧异步复制 | 中心可能落后边缘 | 分区内通过副本复制、ISR 与 Leader 选举维护一致性 |
| 依赖 MirrorMaker | 是 | 是 | 是 | 否 |
| 典型跨机房距离 | 取决于网络条件 | 取决于网络条件 | 取决于网络条件 | 同 region 内 |
| 复杂度 | 中 | 高 | 中 | 低（另需跨 AZ 网络与副本布局） |
表中描述的是常见部署方式，并非各拓扑固化的 SLA；RPO、RTO 与可用性目标需结合具体配置与故障演练确定。
3. 选型决策树
需要跨 region 容灾？
│
┌───────────┴───────────┐
否 是
│ │
同 region 内多 AZ？ 用户是否分散多 region？
│ │
Stretch Cluster ┌─────────┴─────────┐
是 否
│ │
读写就近？ 核心域 or 分析？
│ │
Active-Active ┌─────────┴────────┐
核心域 分析
│ │
Active-Standby Hub-and-Spoke上述决策树是快速选型的参考路径。多集群架构常需要组合部署，例如区域内采用 Stretch Cluster 做多 AZ 容灾，同时通过 MM2 向另一个 region 的备集群复制；不必把四种拓扑理解为严格四选一。
4. 与 Cluster Linking / Confluent Replicator 的关系
MirrorMaker 2 不是唯一选择：
| 工具 | 定位 | 许可 |
|---|---|---|
| MirrorMaker 2 | Apache Kafka 官方，基于 Kafka Connect | Apache 2.0 |
| Confluent Replicator | Confluent 商业版跨集群复制 | 商业许可 |
| Confluent Cluster Linking | Broker 原生跨集群订阅，无 Connect 中转 | 商业许可 |
| Uber uReplicator | Uber 自研，早期为解决 MM1 局限 | 开源 |
| LinkedIn Brooklin | LinkedIn 自研，多源多目标数据管道 | 开源 |
本文后续以 Apache Kafka 官方的 MirrorMaker 2 为主线，介绍拓扑设计、复制配置、消费者位点转换和灾备演练。其他实现的维护状态、兼容性与运维成本需结合具体项目单独评估。
5. 本目录导航
| 章节 | 主题 |
|---|---|
| §2 MirrorMaker 2 架构与配置 | 三个 Connector、内部 topic、DefaultReplicationPolicy |
| §3 Offset 翻译与消费者切换 | offset-syncs / checkpoints 机制、RemoteClusterUtils |
| §4 灾备演练与切换流程 | Runbook、切流量顺序、回切策略 |