129 lines
4.8 KiB
Markdown
129 lines
4.8 KiB
Markdown
---
|
||
tags:
|
||
- MQ
|
||
create time: 2026-05-24 19:52
|
||
---
|
||
|
||
# MQ 跨集群复制与容灾
|
||
|
||
## 概述
|
||
|
||
当单一 MQ 集群无法满足灾备、合规或多地域低延迟访问的需求时，跨集群复制成为必选项。本文深入分析 Kafka 和 RocketMQ 的跨集群复制方案，探讨 MirrorMaker 2.0 的工作原理，以及异地多活架构的实现思路。
|
||
|
||
## 正文
|
||
|
||
### 跨集群复制的需求
|
||
|
||
为什么不能只靠一个集群？四类典型需求驱动了跨集群复制：
|
||
|
||
1. **灾备**：主机房不可用时，备集群接管流量，RTO/RPO 需要可控。
|
||
2. **数据迁移**：从一个集群迁移到另一个（比如跨云迁移），要求业务无感知。
|
||
3. **就近访问**：全球业务需要各区域就近接入，降低网络延迟。
|
||
4. **合规要求**：某些数据法规（如 GDPR）要求数据不得离开特定区域，但仍需全局分析。
|
||
|
||
> [!question]
|
||
> 如果你的 MQ 集群需要同时服务中国和欧洲用户，你会选择一个全球集群还是两个区域集群？各自的 Trade-off 是什么？
|
||
|
||
### Kafka 跨集群方案
|
||
|
||
**MirrorMaker 2.0**
|
||
|
||
MirrorMaker 2.0（简称 MM2）是 Kafka 官方的跨集群复制工具，基于 Kafka Connect 构建。它的核心流程很直观：
|
||
|
||
1. 从远端集群消费消息
|
||
2. 写入本地集群的对应 Topic
|
||
3. 维护 Offset 映射关系
|
||
|
||
```mermaid
|
||
graph LR
|
||
subgraph "源集群 DC-A"
|
||
TA["Topic-A"]
|
||
TB["Topic-B"]
|
||
end
|
||
subgraph "MirrorMaker 2.0"
|
||
C1["Source Connector"]
|
||
T["转换层 - Topic重命名, Offset映射"]
|
||
C2["Sink Connector"]
|
||
end
|
||
subgraph "目标集群 DC-B"
|
||
TA2["dc-A.Topic-A"]
|
||
TB2["dc-A.Topic-B"]
|
||
end
|
||
TA --> C1
|
||
TB --> C1
|
||
C1 --> T
|
||
T --> C2
|
||
C2 --> TA2
|
||
C2 --> TB2
|
||
```
|
||
|
||
MM2 的几个关键设计点：
|
||
|
||
- **Topic 名称转换**：默认在目标集群加前缀（如 `dc-A.topic-A`），避免命名冲突。
|
||
- **Offset 映射**：MM2 会创建一个 `__consumer_offsets` 的映射 Topic，记录源集群和目标集群的 Offset 对应关系。这样消费者在故障切换后能从正确的位置继续消费。
|
||
- **自动同步配置**：Topic 分区数、副本因子等配置变更也会自动同步。
|
||
|
||
```go
|
||
// MM2 Offset 映射的核心概念（简化示意）
|
||
type OffsetSync struct {
|
||
UpstreamOffset int64 // 源集群的 Offset
|
||
DownstreamOffset int64 // 目标集群的 Offset
|
||
Timestamp int64
|
||
}
|
||
|
||
// 故障切换时，根据映射找到目标集群的对应 Offset
|
||
func TranslateOffset(syncs []OffsetSync, upstreamOffset int64) int64 {
|
||
// 二分查找最近的映射点
|
||
for i := len(syncs) - 1; i >= 0; i-- {
|
||
if syncs[i].UpstreamOffset <= upstreamOffset {
|
||
return syncs[i].DownstreamOffset
|
||
}
|
||
}
|
||
return 0
|
||
}
|
||
```
|
||
|
||
**Confluent Replicator**
|
||
|
||
Confluent 的商业方案，相比 MM2 更成熟，支持自动 Topic 创建、配置同步、Offset 翻译，但需要 Confluent Platform 授权。
|
||
|
||
**Cluster Linking（Confluent 7.0+）**
|
||
|
||
这是 Confluent 最新的方案，直接在 Broker 层面建立集群间的链接，不需要额外的 Connect 集群。性能更好，延迟更低，但仅限 Confluent 平台。
|
||
|
||
### RocketMQ 跨集群方案
|
||
|
||
RocketMQ 的跨集群方案相对简单：
|
||
|
||
- **DLedger 多副本**：基于 Raft 协议的副本同步，适合同城双活场景，RPO = 0。
|
||
- **RocketMQ Bridge**：类似 Kafka MM2 的桥接组件，支持跨集群消息转发。
|
||
|
||
### 跨地域同步的挑战
|
||
|
||
跨集群复制不是简单的消息转发，面临几个硬核挑战：
|
||
|
||
**网络延迟**：跨地域网络延迟通常 50-200ms，同步复制会严重影响吞吐。大多数场景只能用异步复制，这意味着 RPO > 0。
|
||
|
||
**消息顺序**：源集群保证了分区内的顺序，但复制到目标集群后，由于网络抖动和并行复制，可能出现乱序。解决方案是按 Key 哈希到同一分区，牺牲并行度换取顺序。
|
||
|
||
**冲突解决**：双向复制（Active-Active）场景下，两端可能同时修改同一份数据。常见策略有 Last-Write-Wins（LWW）和基于版本号的冲突检测。
|
||
|
||
**带宽成本**：跨地域带宽昂贵。可以通过压缩、批量发送、限速等手段控制成本。
|
||
|
||
### 异地多活架构
|
||
|
||
异地多活是最复杂的跨地域方案，核心思想是每个区域都能独立提供完整服务：
|
||
|
||
- **写本地读本地**：每个区域的 Producer 和 Consumer 都连接本地集群，避免跨地域调用。
|
||
- **全局 Topic 路由**：通过全局路由层，将请求导向用户所在的区域集群。
|
||
- **冲突检测与合并**：对于需要全局一致的数据，采用 CDC（Change Data Capture）+ 冲突解决机制。
|
||
|
||
> [!question]
|
||
> 异地多活下，如果用户 A 在中国下单，同时用户 B 在美国查看库存，如何保证库存数据的一致性？
|
||
|
||
## 关联笔记
|
||
|
||
- [[44-MQ-高可用架构]]
|
||
- [[46-MQ-分布式事务实践]]
|
||
- [[51-云消息服务]]
|