设计目标

基于对应用场景和技术挑战的分析，我们可以明确分布式 ID 生成器的核心设计目标。这些目标将成为我们选择和设计方案的重要依据。

核心目标

1. 全局唯一性 ⭐⭐⭐⭐⭐

定义：在整个分布式系统中，每个 ID 都必须是唯一的，绝对不能重复。

重要性：这是最核心、最重要的需求，没有讨价还价的余地。

成功标准：

- 0 个重复 ID
- 理论证明不重复
- 实践验证无冲突

失败代价：

• 订单号重复 → 支付失败
• 用户 ID 冲突 → 数据混乱
• 消息 ID 重复 → 追踪失败
• 数据量越大，影响越严重

2. 有序性 ⭐⭐⭐⭐

定义：ID 应该按时间趋势递增，而不是严格递增。

重要性：有序性对数据库性能和业务查询都很重要。

有序性级别：

严格递增：1, 2, 3, 4, 5
趋势递增：1001, 1002, 998, 1003, 1005
大致有序：按时间大致排序
无序：完全随机

业务价值：

• 数据库索引：递增 ID 有利于 B+ 树索引性能
• 范围查询：便于按时间范围查询
• 分页查询：结果有序便于分页
• 数据恢复：有序数据便于恢复和回溯

3. 高性能 ⭐⭐⭐⭐

定义：ID 生成要快，不能成为系统的性能瓶颈。

性能指标：

QPS：> 100,000
延迟：P99 < 1ms
可用性：99.99%

性能要求：

• 本地生成：避免网络开销
• 无阻塞：不影响业务流程
• 可扩展：水平扩展支持更高 QPS

性能对比：

UUID 本地生成：100万+ QPS
数据库自增：5万 QPS (单机)
雪花算法：100万+ QPS

4. 高可用性 ⭐⭐⭐⭐

定义：ID 生成服务在任何情况下都不能停止工作。

可用性目标：

- 99.99% 可用性 (每年停机 < 52分钟)
- 99.999% 可用性 (每年停机 < 5分钟)

故障场景覆盖：

• 单节点故障
• 单机故障
• 机房故障
• 网络分区
• 时钟回拨

高可用策略：

• 多节点部署
• 无单点故障
• 快速故障转移
• 降级方案

5. 可扩展性 ⭐⭐⭐

定义：能够随着业务增长平滑扩展。

扩展性要求：

- 支持水平扩展
- 扩展过程平滑
- 扩展成本低

扩展维度：

• QPS 扩展：从 10万到 1000万 QPS
• 容量扩展：从 1亿到 1000亿 ID
• 节点扩展：从 1 节点到 1000 节点

次要目标

6. 信息安全 ⭐⭐

定义：ID 不应该泄露业务敏感信息。

安全性考虑：

❌ ID 暴露用户量：10000001 → 只有100万用户
❌ ID 暴露业务量：订单号递增明显
✅ ID 不泄露信息：随机或加密

实际应用：

• 某些场景需要可读 ID（如订单号）
• 某些场景需要随机 ID（如用户ID）
• 需要根据业务场景权衡

7. 短小精悍 ⭐⭐

定义：ID 长度要合理，不过长也不过短。

长度对比：

UUID：36字符 (偏长)
雪花算法：64位数值 (8字节)
号段模式：19位数值 (可接受)

存储成本：

每表1000万条数据
UUID：360MB 存储
64位数值：80MB 存储
节省 77% 存储空间

目标冲突与权衡

冲突场景

唯一性 vs 性能：

全局协调保证唯一：性能差
本地生成保证性能：唯一性难保证

有序性 vs 分布式：

严格有序：需要全局协调
分布式：各节点独立，难以严格有序

短小 vs 信息安全：

短ID：容易被推测
长ID：信息更多但存储成本高

权衡策略

根据业务场景进行权衡：

设计目标优先级

强制要求（必须满足）

1. 全局唯一：不可妥协
2. 高可用性：不可妥协
3. 基本性能：不成为瓶颈

重要要求（尽量满足）

4. 趋势递增：对性能有帮助
5. 可扩展性：长期发展需要

可选要求（根据场景）

6. 信息安全：根据业务决定
7. 短小精悍：成本考虑

目标达成标准

每个方案都要回答

1. ✅ 如何保证全局唯一？
2. ✅ 如何保证趋势递增？
3. ✅ 性能如何？QPS 和延迟？
4. ✅ 如何保证高可用？
5. ✅ 如何水平扩展？
6. ⚪ 是否泄露业务信息？
7. ⚪ ID 长度是否合理？

下一步

明确了设计目标后，我们开始学习具体的 ID 生成方案。

👉 下一章：基础概念 - ID 的特性要求