Kafka 跨集群地理复制（Geo-Replication）

1. 为什么要做 Geo-Replication？

组织、技术与合规经常要求跨集群/跨地域的数据流。典型场景：

• 跨地域复制与灾难恢复（DR）
• 边缘集群汇入中心聚合集群（Aggregate）
• 物理隔离（生产 vs 测试）
• 云迁移 / 混合云
• 法律合规（数据驻留、跨境流动控制）

**MM2（MirrorMaker v2）**构建在 Kafka Connect 上，提供：主题（含配置）复制、消费组与位点迁移（便于应用切换）、ACL 复制、保持分区策略、自动发现新主题/分区、丰富指标与横向扩展能力。

注：Geo-Replication 是跨集群复制，不同于 Kafka 集群内副本复制。

2. 复制流（Replication Flows）与常见拓扑

复制流是从源集群到目标集群的有向通道，配置语法为 {source}->{target}。可拼装出多种拓扑：

• 主主（Active/Active）：A->B, B->A
• 主备（Active/Passive）：A->B
• 聚合（多→一）：A->K, B->K, C->K
• 扇出（一→多）：K->A, K->B, K->C
• 转发链：A->B, B->C, C->D

每条复制流可独立配置复制的主题/消费组（支持正则与排除规则）。

3. 推荐架构与部署位置

3.1 “远端消费，本地生产”（强烈推荐）

将 MM2 进程部署在靠近目标集群（即生产端）的机房，最小化 producer 侧网络抖动与时延。

Remote（源） ----(consume)----> MirrorMaker ----(produce)----> Local（目标）

运行时在命令行使用：

bin/connect-mirror-maker.sh connect-mirror-maker.properties --clusters <local-aliases>

--clusters 告知该进程：这些别名是近端集群，避免向远端推送配置/写入，降低跨域成本与“producer lag”。

3.2 不建议：单一集群跨多 DC

跨高延迟链路会带来写入复制时延飙升与可用性脆弱性，除非是极低 RTT 专线且有强一致场景诉求，一般不采纳。

4. 配置文件全解（connect-mirror-maker.properties）

4.1 全局与集群别名

clusters = us-west, us-east          # 定义别名
us-west.bootstrap.servers = broker3-west:9092
us-east.bootstrap.servers = broker5-east:9092# 顶层默认复制范围（可被具体流覆盖）
topics = .*                           # 主题默认全部
# groups = .*                         # 消费组默认全部（也可显式指定）

4.2 启用复制流与局部覆盖

# 启用 us-west -> us-east
us-west->us-east.enabled = true
# 仅复制 foo.*, bar.*（覆盖顶层 topics）
us-west->us-east.topics = foo.*, bar.*
# 也可限制复制的消费组
# us-west->us-east.groups = bar.*

复制是有方向的；双向需显式配置两条流。
默认会复制除系统/内部外的大多数主题与组（有默认 exclude 规则，可再叠加自定义）。

4.3 Kafka Connect 与任务并行度

# Connect Worker 层设置（MirrorMaker 直接复用）
tasks.max = 5   # 多进程/多分区复制建议 >=2，视硬件与分区总量而定

4.4 每集群定制的客户端设置

# 从 us-west 消费：过滤中止事务（建议）
us-west.consumer.isolation.level = read_committed
us-west.admin.bootstrap.servers = broker57-primary:9092# 向 us-east 生产：压缩与内存
us-east.producer.compression.type = gzip
us-east.producer.buffer.memory = 32768
us-east.admin.bootstrap.servers = broker8-secondary:9092

4.5 Exactly-Once（EOS）配置与升级路径（3.5.0+）

• 新集群：对需要以 EOS 写入的目标集群启用：

  us-east.exactly.once.source.support = enabled
  

• 已运行集群：两步升级：先设 preparing（所有节点）→ 重启 → 再设 enabled（所有节点）→ 重启。

并开启 KIP-710 的节点间内部 REST 通信：

dedicated.mode.enable.internal.rest = true
listeners = http://localhost:8080  # 生产务必加固 REST 安全

5. 主题命名策略与环路防止

5.1 目标集群中的主题重命名

默认策略 DefaultReplicationPolicy：
{source}.{source_topic_name} → 例如 us-west.foo-topic。
可通过分隔符定制：

us-west->us-east.replication.policy.separator = _
# 结果示例：us-west_foo-topic

如需完全自定义，编写 ReplicationPolicy 并设置：

replication.policy.class = <your.class.name>

5.2 复制“环路”

双向流定义在同一份 MM2 配置文件时，MM2 会避免把已复制主题再次回传，通常无需额外 topics.exclude。
若多套配置/多进程混合，请谨慎加入 exclude 规则避免环回。

6. 安全与合规

MirrorMaker 继承 Kafka Connect 的安全能力：SASL/SCRAM、TLS、ACL 复制等。示例（加密到 us-east）：

us-east.security.protocol=SSL
us-east.ssl.truststore.location=/path/to/truststore.jks
us-east.ssl.truststore.password=****
us-east.ssl.keystore.location=/path/to/keystore.jks
us-east.ssl.keystore.password=****
us-east.ssl.key.password=****

生产环境：加固 REST（启用内部通信时），最小权限 ACL，按数据驻留策略限制跨境/跨区复制的话题。

7. 快速上手：三类模板

7.1 主备（Active/Passive）

primary.bootstrap.servers = broker1-primary:9092
secondary.bootstrap.servers = broker2-secondary:9092primary->secondary.enabled = true
secondary->primary.enabled = false
primary->secondary.topics = foo.*     # 仅复制部分主题

7.2 主主（Active/Active）

clusters = us-west, us-east
us-west.bootstrap.servers = broker1-west:9092,broker2-west:9092
us-east.bootstrap.servers = broker3-east:9092,broker4-east:9092us-west->us-east.enabled = true
us-east->us-west.enabled = true

7.3 多数据中心（单 DC 内主主 + 跨 DC 互联）

clusters = west-1, west-2, east-1, east-2, north-1, north-2
# ... 各自 bootstrap ...# DC 内部主主
west-1->west-2.enabled = true
west-2->west-1.enabled = true
east-1->east-2.enabled = true
east-2->east-1.enabled = true
north-1->north-2.enabled = true
north-2->north-1.enabled = true# 跨 DC（以 *-1 为桥）
west-1->east-1.enabled  = true
west-1->north-1.enabled = true
east-1->west-1.enabled  = true
east-1->north-1.enabled = true
north-1->west-1.enabled = true
north-1->east-1.enabled = true

各 DC 启动时固定“近端”：

# West DC:
bin/connect-mirror-maker.sh connect-mirror-maker.properties --clusters west-1 west-2
# East DC:
bin/connect-mirror-maker.sh connect-mirror-maker.properties --clusters east-1 east-2
# North DC:
bin/connect-mirror-maker.sh connect-mirror-maker.properties --clusters north-1 north-2

8. 启停与变更

• 启动：

  bin/connect-mirror-maker.sh connect-mirror-maker.properties
  # 可选只写近端：
  bin/connect-mirror-maker.sh connect-mirror-maker.properties --clusters us-west
  

  首次启动到开始复制可能需要几分钟（任务初始化/发现主题）。

• 停止：

  kill <MirrorMaker pid>  # 发送 SIGTERM 即可优雅退出
  

• 配置变更：
  修改后重启进程生效（涉及 EOS 升级请遵循两步重启流程）。

测试消费组复制时注意：默认 groups.exclude 会排除 kafka-console-consumer.sh 产生的组；如需测试位点复制须先放开，测试结束再恢复默认。

9. 监控与告警（必配）

MM2 继承 Connect 指标，并在 kafka.connect.mirror 组输出专属指标。标签包含：

• source（源别名）、target（目标别名）
• topic（目标侧复制主题名，如 primary.topic1）
• partition

核心指标（节选）

# MirrorSourceConnector 维度（target, topic, partition）
record-count / record-rate
byte-count / byte-rate
record-age-ms(min/max/avg)
replication-latency-ms(min/max/avg)    # 端到端复制时延# MirrorCheckpointConnector 维度（source, target, group, topic, partition）
checkpoint-latency-ms(min/max/avg)     # 消费位点复制时延

建议告警：replication-latency-ms、record-age-ms、任务状态（running/failed）、checkpoint-latency-ms、吞吐（byte-rate）异常突变。

10. 性能与稳定性调优要点

• 并发与切片：tasks.max ≥2，并与复制分区总量匹配；必要时多起进程水平扩。
• Producer 调优（目标侧）：compression.type（gzip/zstd）、buffer.memory、batch.size、linger.ms；
  高 RTT 链路按带宽×RTT估算socket 缓冲，并保证 OS 层限值同步放大。
• Consumer 调优（源侧）：isolation.level=read_committed（过滤中止事务，配合 EOS），fetch.* 合理放大。
• 避免配置竞态：同一目标集群的复制流配置应统一，避免不同 MM2 进程对同一目标给出相互覆盖的 topics 选择（否则会出现“谁是 leader 谁说了算”的不确定性）。

配置冲突示例（反例）

# 进程1
A->B.enabled = true
A->B.topics  = foo# 进程2
A->B.enabled = true
A->B.topics  = bar

解决：用统一配置或组织级自动化生成配置，确保同一目标上的复制定义一致。

11. 常见问题（FAQ）

Q1：如何防止双向复制的“环路”？
A：双向流定义在同一份 MM2 配置时，默认已避免环回；多份配置混用时需用 topics.exclude 显式排除远端前缀主题。

Q2：消费组位点一定要复制吗？
A：用于迁移应用时非常有用；常规跨域读写建议目标侧使用新的消费组，避免位点耦合。

Q3：Exactly-Once 必须启用吗？
A：按业务需求选。EOS 提升一致性保障，但会带来资源与复杂度开销；升级请遵循 preparing -> enabled 的两阶段流程，并启用内部 REST。

Q4：为什么我在目标集群看不到源主题同名？
A：默认会按 {source}.{topic} 重命名；可通过 replication.policy.separator 或自定义 ReplicationPolicy 控制。

---

12. 上线 Checklist（精简版）

• 明确复制拓扑（主主/主备/聚合/扇出/转发）
• 统一配置文件（含 clusters、flows、topics/groups(include & exclude)）
• 生产安全：SASL/TLS、ACL 与证书生命周期
• 调优：tasks.max、Producer/Consumer/Socket 缓冲与批量
• 位置：MM2 部署在目标集群附近，并使用 --clusters
• 监控：MirrorSource/MirrorCheckpoint 指标与任务状态告警
• （可选）EOS：exactly.once.source.support、KIP-710 内部 REST 加固
• 变更流程：改配 → 滚动重启 → 验收延迟与吞吐
• 回退预案：topics 范围收敛、停特定流、逐步降载