集群模式

单库自增无法满足分布式系统的需求，让我们学习如何在数据库集群中生成唯一 ID。

问题分析

1. 单库的限制

问题：

单数据库实例：
- 无法水平扩展
- 单点故障
- 性能瓶颈

影响：

• QPS 受限于单机性能
• 数据库故障导致系统不可用
• 无法支持大规模系统

集群方案

1. 不同起始值

原理： 为每个数据库实例设置不同的起始值和相同的步长。

配置：

数据库 A：起始值 1，步长 3
数据库 B：起始值 2，步长 3
数据库 C：起始值 3，步长 3

生成的 ID：
数据库 A：1, 4, 7, 10, 13, ...
数据库 B：2, 5, 8, 11, 14, ...
数据库 C：3, 6, 9, 12, 15, ...

实现：

数据设计要点

• 核心是在 users 里保存业务事实，而不是把规则散落在应用逻辑里。
• 索引服务于高频查询，重点是缩小扫描范围，而不是堆更多字段。
• 关键字段包括 id、name，它们决定后续查询和管理能力。

方案落地：

2. 不同步长

原理： 为每个数据库实例设置相同的起始值和不同的步长。

配置：

数据库 A：起始值 1，步长 2
数据库 B：起始值 2，步长 2

生成的 ID：
数据库 A：1, 3, 5, 7, 9, ...
数据库 B：2, 4, 6, 8, 10, ...

实现：

数据设计要点

• 这里关注数据模型和约束关系，不需要记住具体语法。

高可用设计

1. 主从复制

架构：

┌─────────┐  ┌─────────┐  ┌─────────┐
│ 节点 A  │  │ 节点 B  │  │ 节点 C  │
│  Master │  │  Master │  │  Master │
└────┬────┘  └────┬────┘  └────┬────┘
     │            │            │
     └────────────┼────────────┘
                  │
           负载均衡器

实现：

2. 故障转移

策略：

1. 健康检查：定期检查数据库状态
2. 故障检测：快速发现故障数据库
3. 流量切换：将流量切换到健康数据库
4. 自动恢复：故障恢复后重新加入

实现：

数据一致性

1. 同步复制

问题：

主库写入后，从库同步需要时间
可能导致：
- 数据不一致
- ID 冲突

解决：

数据设计要点

• 这里关注数据模型和约束关系，不需要记住具体语法。

2. 最终一致性

策略：

1. 允许短暂不一致
2. 定期同步数据
3. 冲突检测和解决
4. 数据修复机制

性能优化

1. 批量获取

实现：

适用场景

✅ 适合使用

1. 中型系统

- 需要一定高可用
- QPS < 10,000
- 多数据库实例

2. 数据库集群

- 已有数据库集群
- 需要利用现有集群
- 不想引入新组件

❌ 不适合使用

1. 高并发系统

- QPS > 100,000
- 需要极低延迟
- 数据库压力大

2. 跨机房系统

- 跨机房部署
- 网络延迟高
- 数据同步复杂

总结

集群模式评价

使用建议

推荐使用：

✅ 已有数据库集群
✅ 中型规模系统
✅ 需要高可用
✅ 不想引入新组件

不推荐使用：

❌ 高并发系统
❌ 跨机房部署
❌ 极高性能要求

下一步

了解了集群模式后，我们学习步长策略优化。

👉 下一节：步长策略