如何设计一个分布式 ID 生成系统？
设计一个分布式 ID 生成系统的核心目标是：在多节点环境下，生成全局唯一、趋势递增、高性能、低延迟的 ID，同时避免单点瓶颈。
下面从「需求 → 方案 → 经典算法 → 架构设计 → 权衡」系统讲清楚。
一、核心需求
一个好的分布式 ID 系统通常要满足：
1. 全局唯一
不能重复（必须条件）
2. 高性能
通常要求：
QPS：10万 ~ 千万级
单次生成 < 1ms
3. 趋势递增（可选但常见）
数据库索引友好（如 MySQL InnoDB）
不要求严格递增，但要“基本有序”
4. 可用性高
不能依赖单点
故障可恢复
5. 可扩展
支持多机房、多集群
二、常见设计方案对比
1. 数据库自增 ID（不推荐用于分布式）
方案：
MySQL AUTO_INCREMENT
问题：
单点瓶颈
扩展困难
多库冲突
👉 只能用于小规模系统
2. UUID（完全分布式）
例如：
550e8400-e29b-41d4-a716-446655440000优点：
无中心
天然唯一
缺点：
无序（影响索引性能）
占空间大（128 bit）
查询性能差
👉 适合：日志、文件名、非结构化场景
3. Snowflake（最主流）
Twitter 提出的经典方案 ⭐⭐⭐⭐⭐
三、Snowflake 核心思想
一个 64-bit long 类型 ID：
0 - 41bit 时间戳 - 5bit 数据中心 - 5bit机器ID - 12bit序列号结构如下：
| 部分 | 位数 | 含义 |
|---|---|---|
| 符号位 | 1 | 固定0 |
| 时间戳 | 41 | 毫秒级时间 |
| 数据中心ID | 5 | 0~31 |
| 机器ID | 5 | 0~31 |
| 序列号 | 12 | 每毫秒内计数 |
1. 时间戳（核心排序依据）
支持约 69 年（2^41 ms）
保证 ID 趋势递增
2. 机器 ID（分布式关键）
来源：
手动配置
ZooKeeper / etcd 分配
Kubernetes Pod Identity
3. 序列号（同毫秒并发）
每毫秒最多 4096 个 ID
超过则等待下一毫秒
四、Snowflake 生成流程
if 当前时间 == 上次时间: sequence++ else: sequence = 0 if sequence > 4095: 等待下一毫秒 ID = (timestamp << shift) | (datacenterId << shift) | (workerId << shift) | sequence五、架构设计（生产级）
1. 单机版 Snowflake
App ↓ ID Generator（本地服务）优点：
极快（内存计算）
无网络开销
缺点：
机器 ID 管理麻烦
2. 服务化 ID 生成器（推荐）
┌────────────┐ │ API Gateway│ └─────┬──────┘ ↓ ┌────────────────────┐ │ ID Service Cluster │ │ Node1 Node2 Node3 │ └────────────────────┘ ↓ etcd / ZK（分配 workerId）优点：
统一管理
易扩展
可监控
3. 多机房架构
Region A → Snowflake A Region B → Snowflake B通过：
datacenterId 区分
避免跨机房依赖
六、关键工程问题（面试重点）
1. 时钟回拨问题（非常重要 ⚠️）
问题：
机器时间被 NTP 回拨，会导致 ID 重复
解决方案：
方案 A：拒绝服务
如果当前时间 < 上次时间： 报错方案 B：等待
等待时间追上方案 C：备用逻辑（推荐）
使用逻辑时钟
或切换 workerId
2. workerId 如何分配？
常见方式：
1）ZooKeeper / etcd
临时节点
自动释放
2）数据库分配
worker_id table: node_ip -> id3）启动随机 + 冲突检测（不推荐）
3. 高并发优化
无锁 CAS
线程本地缓存
单机百万 QPS
4. 跨语言支持
ID 生成逻辑需：
Java / Go / Python 实现一致
bit 位严格对齐
七、其他变种方案
1. Leaf（美团方案）
两种模式：
Leaf-Snowflake
改进 Snowflake（解决时钟问题）
Leaf-Segment（更稳定）
DB: id_table: biz_tag | max_id | step一次批量取一段：
[1 ~ 1000] [1001 ~ 2000]👉 优点：
无时钟问题
DB 压力小
👉 缺点：
不严格递增
依赖 DB
2. Redis INCR
INCR global_id优点：
简单
缺点：
Redis 单点
高并发瓶颈
八、如何选择（非常重要）
| 场景 | 推荐方案 |
|---|---|
| 高性能订单系统 | Snowflake |
| 电商订单（强稳定） | Leaf Segment |
| 日志/追踪 | UUID |
| 小系统 | DB 自增 |