目录
2.3 双活(Active-Active / Multi-Master)
2.5 延展集群(Scale-out / Aggregation Tiers)
3.Kafka 的 MirrorMaker(Connect-based)——如何配置 / 部署 /调优
3.1 MirrorMaker(Connect)基本配置示例(单向复制)
4.2 Confluent Replicator / Cluster Linking(商业增强)
5.实施步骤(Check-list / Runbook 摘要)

包含:场景、常见多集群拓扑、MirrorMaker(Connect-based)配置/部署/调优,以及主流替代方案(uReplicator、Confluent Replicator / Cluster Linking)。
说明:Apache Kafka 的镜像实现以 Kafka Connect(MM2 / Connect-based MirrorMaker)为基础,厂商在此基础上有各自增强(Confluent 的 Replicator / Cluster Linking、Uber 的 uReplicator 等)。(kafka.apache.org)
1.扩集群镜像的典型使用场景(Why / When)
灾备(DR)/容灾恢复:跨机房或跨可用域复制关键 topic,出现故障时可切换到镜像集群继续服务。
跨地域读就近(Latency reduction):将热点数据复制到多个区域,降低读取延迟和带宽成本(读多写少场景)。
数据迁移 / 集群扩容:把已有 topics 无缝迁移到新集群(滚动迁移、分阶段迁移)。
多活 / 全球总线(Aggregation):在全球多区写入并将数据汇总到中央分析集群或对等镜像实现双活读写。
合规 / 备份(audit / archival):把业务数据镜像到专用审计/归档集群或长期存储。
跨云 / 混合云互通:私有云 ↔ 公有云间的数据同步。
每种场景对延迟、一致性(是否可丢)、带宽、双向循环(cycle)控制、写入冲突策略要求不同 —— 设计镜像拓扑前必须明确业务 SLO(RPO/RTO、可接受延迟、是否允许重复/丢失)。
2.多集群架构模式(概念 + 何时用哪个)
下面给出常见模式、优缺点与适用场景,并配 ASCII 示意图。
2.1 跨数据中心通信的常见挑战(高层列举)
网络波动与带宽限制:跨区延迟高、封包丢失导致复制滞后。
安全与认证:需要 TLS/SASL、ACL 与防火墙穿透。
Topic 命名、分区、Retention 差异导致不一致。
循环复制(A→B→A)风险:需要 cycle-avoid 策略(topic rename / origin metadata)。
监控与故障切换复杂度高(需要可观测性)。
2.2 Hub & Spoke(集中汇聚)
示意:
Region A Region B Region C
\ | /
\ | /
\ | /
\ | /
--> Hub Cluster <-- (Central aggregation cluster)
特点/适用:
多个区域写入/采集 → 汇聚到中央分析/数据湖。
中央化管理,易实现统一处理/归档。 缺点:Hub 成为单点流量/存储瓶颈(需水平扩展);跨区带宽成本高。
2.3 双活(Active-Active / Multi-Master)
示意(simplified):
Region A <----> Region B
topic-a topic-a
(writes) (writes)
特点/适用:
两地都可以写入,读就近。适用于强可用、低延迟全球业务(需要业务层合并/冲突解决)。 关键难点:写冲突、重复消息、顺序保证、cycle 避免、全局唯一 id 策略。通常需要在消息中带来源标识并用合并策略(CRDT / last-write / upsert)处理冲突。
2.4 主备(Active-Passive / DR)
示意:
Active Cluster ---> Passive Mirror (replicated)
(primary) (standby)
特点/适用:
备用集群仅用于容灾;平时只读或不对外服务。
简单、切换可控。适合灾备需求高但写入单一场景。 注意:切换过程可能需要 offset / consumer group 迁移与验证。
2.5 延展集群(Scale-out / Aggregation Tiers)
示意:
Region clusters -> Aggregation clusters -> Global analytics cluster
特点:
多层镜像,分层汇聚(减小跨区域流量峰值影响)。
适用于超大规模架构(Uber 类场景)。Uber 的 uReplicator 即适用于大规模分层聚合。(Uber)
3.Kafka 的 MirrorMaker(Connect-based)——如何配置 / 部署 /调优
说明:Apache 官方的镜像实现基于 Kafka Connect(即 MM2 / Connect-based MirrorMaker)。不同发行(Apache vs Confluent)术语略有差异,但核心思想一致:使用 Connect worker 做 source consumer → produce 到目标集群,并管理 offsets、心跳与 topic remapping。(kafka.apache.org)
下面分 3.1 配置示例、3.2 生产部署建议、3.3 调优技巧。
3.1 MirrorMaker(Connect)基本配置示例(单向复制)
这是一个简化的 mirrormaker.properties(Connect worker + mirror connector)示例(基于 Kafka 官方文档样式):
# Worker-level (Connect distributed) config
bootstrap.servers=mm-worker-bootstrap:9092
group.id=mm2-cluster
key.converter=org.apache.kafka.connect.converters.ByteArrayConverter
value.converter=org.apache.kafka.connect.converters.ByteArrayConverter
offset.storage.topic=mm2-offsets
config.storage.topic=mm2-configs
status.storage.topic=mm2-status
offset.flush.interval.ms=10000
plugin.path=/opt/kafka-connect/plugins
# MirrorMaker connector config (example inside connector.json)
# Using "clusters" map: source cluster id = "us-west", target cluster id = "us-east"
clusters = us-west,us-east
# us-west cluster bootstrap (source)
us-west.bootstrap.servers=us-west-kafka:9092
# us-east cluster bootstrap (target)
us-east.bootstrap.servers=us-east-kafka:9092
# What to replicate: regex or explicit list
replication.policy.class=org.apache.kafka.connect.mirror.DefaultReplicationPolicy
g
浙公网安备 33010602011771号