如何设计一个分布式 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. 时间戳（核心排序依据）

• 支持约 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 -> id

3）启动随机 + 冲突检测（不推荐）

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 单点

• 高并发瓶颈

八、如何选择（非常重要）