ZooKeeper多集群与容灾架构
多集群联邦和容灾多活架构设计。
多集群联邦架构
架构模式：
Java
数据中心A 数据中心B
集群A(3节点) 集群B(3节点)
↓ ↓
联邦路由层 ←----同步----→ 联邦路由层
↓ ↓
客户端A 客户端B
联邦路由层功能：
| 功能 | 说明 |
|---|---|
| 请求路由 | 按数据中心就近访问 |
| 数据同步 | 跨集群数据复制 |
| 故障切换 | 集群故障自动切换 |
数据同步方式：
| 方式 | 说明 | 适用场景 |
|---|---|---|
| 双向同步 | 两集群实时同步 | 同城双活 |
| 单向同步 | 主集群→备集群 | 异地灾备 |
| 定期同步 | 定时批量同步 | 非关键数据 |
联邦路由实现：
Java
// 按数据中心选择集群
String datacenter = getDatacenter();
String zkAddr = switch(datacenter) {
case "A" -> "zk-a1:2181,zk-a2:2181,zk-a3:2181";
case "B" -> "zk-b1:2181,zk-b2:2181,zk-b3:2181";
};
CuratorFramework client = CuratorFrameworkFactory.builder()
.connectString(zkAddr)
.build();
数据同步工具：
Bash
// 监听集群A变更，同步到集群B
TreeCache cache = TreeCache.newBuilder(clientA, "/data").build();
cache.getListenable().addListener((client, event) -> {
if (event.getType() == TreeCacheEvent.Type.NODE_UPDATED) {
// 同步到集群B
clientB.setData().forPath(event.getData().getPath(), event.getData().getData());
}
});
联邦架构优势：
| 优势 | 说明 |
|---|---|
| 负载分散 | 各数据中心独立处理 |
| 延迟降低 | 就近访问本地集群 |
| 容灾能力 | 单集群故障不影响整体 |
提示：跨数据中心部署需考虑网络延迟和数据一致性。
容灾多活架构
同城双活架构：
text
机房A 机房B
集群A(Leader+Follower) 集群B(Follower+Observer)
↑↓同步 ↑↓同步
↓ ↓
客户端A ←---互备---→ 客户端B
特点：两地互备，故障自动切换
异地灾备架构：
text
主数据中心（3节点集群）
↓ 实时/定期数据同步
备数据中心（Observer集群）
↓
故障时切换为主集群
特点：主备模式，故障手动/自动切换
故障切换流程：
text
自动切换：
1. 主集群故障检测
2. 备集群升级为主
3. 客户端自动切换连接
4. 业务恢复服务
手动切换：
1. 确认主集群无法恢复
2. 升级备集群为Leader
3. 更新客户端配置
4. 重启客户端连接
切换脚本示例：
text
#!/bin/bash
# 检测主集群故障
check_cluster_health primary
if [ $? -ne 0 ]; then
# 切换到备集群
update_client_config backup
restart_clients
echo "Switched to backup cluster"
fi
数据同步延迟：
| 场景 | 同步延迟 |
|---|---|
| 同城双活 | <10ms |
| 跨城灾备 | 50-200ms |
| 跨国灾备 | >200ms |
一致性保证：
text
高延迟场景数据可能不一致：
1. 主集群写入成功
2. 同步到备集群有延迟
3. 故障切换可能丢失未同步数据
解决：
1. 强制同步后再返回成功（降低性能）
2. 应用层补偿机制
3. 业务设计容忍短时间不一致
容灾演练：
| 演练内容 | 说明 |
|---|---|
| 定期切换测试 | 验证切换流程 |
| 数据一致性验证 | 对比主备数据 |
- 性能测试 | 测试备集群性能 | | 恢复测试 | 测试主集群恢复 |
注意：异地灾备需考虑同步延迟对一致性的影响。
要点总结
- 多集群联邦实现跨数据中心负载均衡
- 联邦路由层负责请求路由和数据同步
- 同城双活两地互备，延迟<10ms
- 异地灾备主备模式，延迟50-200ms
- 故障切换：检测→升级→切换→恢复
- 高延迟场景需考虑数据一致性
- 定期容灾演练验证切换流程
