前情提要
最近公司因为两次机房故障决定部署同城双机房，方案确定为双活单写
双活单写
两个机房A.B都正常提供服务，所有写操作定位到A机房
// TODO 单写与多写的比较
// TODO 双活和冷备的比较
Kafka双活方案
-
延展集群
我们可以将kafka集群分布的布在两个机房，通过机架信息保证每个主题在每个机房都拥有副本
优点:强一致 高度同步 实现简单
缺点:对Zookeeper的依赖导致双机房下实现较为困难 zookeeper需要过半节点存活 只能防止机房故障 无法防止kafka故障
具体实现：- A机房断网
① 外网断 机器正常 有条件的情况 手动下线A机房kafka broker
② 机器崩溃 所有副本自动转移到B机房 无需手动操作 - B机房断网
① 外网断 机器正常 无影响
② 机器崩溃 无影响 - 专线断 同B机房断网
- A机房断网
-
双活集群 同步数据
在两个机房分别布置一个集群，通过mirrormaker同步数据
优点: 可以应对kafka故障 具有弹性
缺点: 成本高，偏移量难以管理
具体实现:- A机房故障
① 外网断 机器正常 停止A向B的mirrormaker 清空A集群所有数据 ，启动B向A的mirrormaker 手动切换到B集群
② 机器崩溃 切换到B集群 A回复后清空数据 启动B向A的mirrormaker - B机房故障
① 外网断 机器正常 无影响
② 机器崩溃 恢复后启动mirrormaker 无影响 - 专线断
同B机器崩溃情形
- A机房故障
总结
可以看到 两种实现方式 在B集群或专线崩溃时 受到的影响都较小
两个实现方式主要的区别是
第一种方法需要线下操作且需要保证zookeeper集群可用
第二种方法需要管理偏移量和mirrormaker
