多机房 Kafka：跨地域复制和故障切换

验证：真实制造一次主机房整体失联

命令 · python + shell p.produce("mm2-source-topic", value="just-before-outage-0" ~ "-4") # 真实写完立刻不等待 p.flush() $ kill -9 <broker1> <broker2> <broker3> # 真实模拟cluster A(主机房)整体宕机

验证：真实查cluster B(灾备机房)，这5条数据真实都在

真实实测 · 本机执行输出

cluster A整体故障后，cluster B(灾备集群)真实还能读到:
['just-before-outage-0', 'just-before-outage-1', 'just-before-outage-2',
 'just-before-outage-3', 'just-before-outage-4']

这次真实测试里数据一条没丢，但这不意味着"MirrorMaker2能保证零数据丢失"——上一篇《MirrorMaker 2》真实测出的复制延迟大约3秒，这意味着理论上存在一个真实的曝险窗口：任何在这3秒复制延迟内、主机房已经写入但还没被MM2真实同步过去的数据，如果这时候主机房真实彻底宕机，这部分数据就真实丢了。本文这次测试之所以全部数据都到了，是因为从produce到kill这段真实的操作耗时(Python进程启动、ps查pid这些真实的开销)，凑巧超过了MM2完成复制所需要的时间，不是MirrorMaker2真实做到了同步复制。多机房方案的RPO(Recovery Point Objective，可接受的数据丢失量)真实约等于这个复制延迟窗口——本机场景下大约是3秒，真实生产环境跨地域的网络延迟通常比本机loopback网络大得多，RPO窗口也会真实相应变大。

结论：多机房方案真实是在一致性和可用性之间做的权衡

本文这套Active-Passive(主备)架构，正常时候写入只发生在主机房，灾备机房真实只是被动接收复制过来的数据；一旦主机房真实故障，业务需要真实手动或者自动切换到灾备机房继续写入(这一步本文没有实现)。相对的还有Active-Active(双活)架构，两个机房同时对外提供写入服务，用双向的MirrorMaker2实例互相同步——真实的复杂度在于避免消息在两个方向之间无限循环复制，以及两个机房各自独立写入同一个逻辑topic时，读取方要怎么处理两份真实并行增长、顺序不完全一致的数据流。

分步演示：一次真实的主机房故障演练

每一步都是本文上面真实kill掉整个cluster A跑出来的原始结果。

这次数据没丢，但RPO窗口真实存在

这一步新验证的场景

参考与说明

数据来自本机两个真实独立的Kafka集群(延续上一篇的cluster A主机房+cluster B灾备机房搭建)，真实kill -9掉cluster A全部3个broker模拟机房级故障。
和《MirrorMaker 2》一起看：这篇的RPO评估直接依赖那篇测出的真实复制延迟数字。
没有验证：Active-Active双活架构的真实实现；自动化的故障切换和DNS/流量调度机制(本文的"切换"只是手动确认灾备机房数据完整，没有实现真正的业务流量切换)。

下一篇 · KAFKA 内部原理 79

Kafka 与 Redis Stream、RabbitMQ 的区别