《Kafka: The Definitive Guide》 第8章： Cross-Cluster Data Mirroring

一、跨集群鏡像的場景與價值

1. 多區域低延遲訪問

   • 將業務數據從主集群實時復制到多個地理區域的集群，縮短消費者跨區讀取延遲。

2. 災備切換

   • 當主集群出現故障時，可快速將消費流量切換到鏡像集群，確保業務連續性。

3. 集群升級與遷移

   • 在不中斷生產環境的前提下，向新集群同步全量與增量數據，實現平滑遷移。

4. 合規與隔離

   • 不同地域或部門的數據隔離需求，可在各自集群中維護副本，滿足安全與法規要求。

---

二、MirrorMaker 2 體系架構回顧

MirrorMaker 2（以下簡稱 MM2）基于 Kafka Connect 框架擴展而來，核心組件包括：

• Source Cluster Connector：在源集群消費指定 topics。
• Target Cluster Connector：以生產者身份將消息寫入目標集群。
• Heartbeat Topic：用于檢查跨集群鏈路健康。
• Checkpoint Topic：跟蹤鏡像進度，確保精準無漏。
• Replication Policy：控制在目標集群中 Topic、Group ID、ACL 等命名轉換與權限映射。

其運行流程大致為：

1. MM2 從源集群的 __heartbeat、__checkpoint 以及業務 topics 拉取消息。
2. 根據 Replication Policy，將消息寫入目標集群對應的鏡像 topic（默認為 <sourceCluster>.<topic>）。
3. 定期寫入 checkpoint，方便故障重啟后接續。
4. 通過心跳機制監控鏈路狀態，及時發現滯后或中斷。

---

三、詳細配置解讀

以下示例配置展示了一個從集群 A ? B 的單向鏡像，以及雙向互鏡的關鍵選項。

# mm2-cluster.properties
clusters = A, B# 集群 A 配置
A.bootstrap.servers = a1:9092,a2:9092
# 集群 B 配置
B.bootstrap.servers = b1:9092,b2:9092# 單向鏡像：A ? B
A->B.enabled = true
A->B.topics = orders, payments      # 指定需要鏡像的 topics 列表或正則
A->B.sync.topic.configs = true      # 同步源端 topic 的所有配置
A->B.emit.heartbeats.enabled = true # 開啟心跳消息
A->B.emit.checkpoints.enabled = true# 雙向互鏡（可選）
B->A.enabled = true
B->A.topics = .*

• topics：支持逗號分隔、通配符正則或 .*（全部）。
• sync.topic.configs：建議開啟，確保分區數、壓縮方式等一致。
• replication.policy.class：可自定義命名策略，如去除前綴、添加地域標識等。

啟動命令：

bin/connect-mirror-maker.sh mm2-cluster.properties

---

四、鏡像一致性與故障恢復

1. Checkpoint 恢復

   • MM2 定期在源集群的 __checkpoint topic 寫入偏移量，并在目標集群中消費，再將進度存至本地狀態。
   • 重啟后自動讀取上次 checkpoint，繼續從上次位置拉取，避免漏 / 重復。

2. 心跳監控

   • __heartbeat topic 用于監測源集群是否活躍，以及鏈路健康度。
   • 可結合 Prometheus 抓取 kafka_mirrormaker2_heartbeat_lag 等指標，及時報警。

3. 網絡抖動與重試

   • MM2 繼承 Kafka Connect 的重試機制：

     errors.retry.timeout = 600000     # 重試總時長（毫秒）
     errors.retry.delay.max.ms = 60000 # 最大重試間隔
     

   • 對于短暫的網絡抖動或目標端不可用，自動重試，無需人工干預。

---

五、高級用例：多活與環形復制

• 多活部署：

  • 在多個機房同時開啟 A?B、A?C、B?C 鏡像，實現三活互備。
  • 需注意：環形復制易產生回環，必須開啟 replication.policy.class = org.apache.kafka.connect.mirror.DefaultReplicationPolicy，并默認過濾已鏡像的前綴。

• 漸進式遷移：

  1. 全量同步：先將歷史數據復制到新集群。
  2. 增量鏡像：開啟 MM2 單向鏡像，捕獲實時寫入。
  3. 切流：消費者切換到新集群后，停用原鏈路。

---

六、監控與調優

指標名稱	含義	建議
checkpoint-lag	已復制偏移與源端最新偏移的差值	<1000 messages
heartbeat-latency	心跳寫入與消費的延遲	<1s
replication-backlog	待發送消息緩沖區大小	根據帶寬調優
task-poll-interval-ms	Connector 拉取輪詢間隔	10–100 ms
consumer/max-poll-records	每次拉取消息數	100–500

• 帶寬與并發：可通過 tasks.max 提升并行度，分散分區負載；
• 壓縮：開啟生產端壓縮（如 compression.type=snappy），減少網絡傳輸量；
• 安全：跨 DC 建議啟用 TLS/SASL，配置 client.dns.lookup=use_all_dns_ips 及 connections.max.idle.ms 保持穩定連接。

---

七、最佳實踐總結

1. 分離全量與增量

   • 對于歷史數據量較大時，采用工具（如 kafka-replay-log-dirs）先行全量導入，再開啟 MM2 進行增量鏡像。

2. 命名策略統一

   • 定制 replication.policy.class，將源集群標識、地區前綴或版本號統一加到 Topic 名稱，便于追蹤與管理。

3. 定期故障演練

   • 模擬主集群故障或鏈路中斷，驗證鏡像集群能否快速接管，檢驗監控告警與自動恢復流程。

4. 流量切分

   • 對于高吞吐主題，可單獨配置專屬 MM2 進程，確保單一鏈路不因其他主題瓶頸拖慢。

5. 權限與隔離

   • 使用 Kafka ACL，嚴控跨集群 MirrorMaker 的讀寫權限，防止誤操作。