分布式唯一 ID 生成方案对比（Snowflake、Leaf、Redis、数据库自增）

在分布式系统中，唯一 ID 是各种业务的基础。本文全面对比主流分布式唯一 ID 生成方案，包括 Snowflake、Leaf、Redis、自增 ID，并结合实际开发中踩过的坑，总结各方案适用场景及最佳实践。

---

🌟 一、唯一 ID 的核心要求

一个优秀的分布式唯一 ID 应具备以下特征：

• 全局唯一性：不能出现重复
• 趋势递增：便于数据库索引优化（如 MySQL InnoDB 主键）
• 高可用：即使某台机器宕机也能继续生成
• 高性能：每秒生成数十万甚至百万级别
• 容错性：网络或时间漂移等情况下仍能保障可用性

---

🔢 二、主流方案对比一览表

方案	唯一性	有序性	性能	依赖性	可用性	成熟度	示例
Snowflake	✅	✅	⭐⭐⭐⭐	本地时间	高	高	Twitter
Leaf	✅	✅	⭐⭐	DB	中	中	美团
Redis	✅	✅	⭐⭐⭐	Redis	中	高	微博
数据库自增	✅	✅	⭐	数据库	低	高	传统系统

---

⛄️ 三、Snowflake 算法（雪花算法）

✅ 原理说明

Snowflake 是 Twitter 开源的一种 64 位 ID 生成算法：

| 1bit | 41bit timestamp | 10bit machineId | 12bit sequence |

• 1bit：符号位，永远为 0
• 41bit：毫秒级时间戳，可使用约 69 年
• 10bit：机器编号，最多支持 1024 台节点
• 12bit：序列号，支持每毫秒 4096 个 ID

✅ 优缺点

优点	缺点
高性能、趋势递增、本地生成	对时间依赖强，时钟回拨需额外处理
无中心化依赖	机器 ID 需配置，不能自动感知

✅ Java 示例

long id = snowflake.nextId();

---

🌿 四、Leaf 美团方案

✅ 原理说明

Leaf 提供两种模式：

1. Leaf-segment（号段模式）：提前从数据库获取一段 ID 范围，服务端缓存使用
2. Leaf-snowflake（本地雪花）：类似 Snowflake

号段模式示例表结构：

CREATE TABLE leaf_alloc (
  biz_tag VARCHAR(128) PRIMARY KEY,
  max_id BIGINT NOT NULL,
  step INT NOT NULL
);

✅ 优缺点

优点	缺点
可控性强、可动态调节号段大小	依赖数据库，初始化复杂
支持多业务 ID 类型	性能受限于数据库 IO

---

🔥 五、Redis 生成方案

✅ 原理说明

Redis 使用 INCR 命令实现自增 ID：

INCR order:id

或带日期前缀：

order:20250731:id => 1, 2, 3, ...

可扩展性强，也支持使用 Lua 脚本 + 位操作构造复杂 ID。

✅ 优缺点

优点	缺点
操作简单、性能高、可搭配前缀使用	Redis 宕机后不可用（需集群）
支持自定义规则（如日期、业务编码）	单点瓶颈（需解决分片、主从一致）

---

🗃️ 六、数据库自增 ID（传统）

✅ 原理说明

使用数据库自带自增主键字段：

CREATE TABLE order (
  id BIGINT AUTO_INCREMENT PRIMARY KEY,
  ...
);

或使用 SELECT 1596677 获取生成值。

✅ 优缺点

优点	缺点
实现简单、适合单体系统	数据库是性能瓶颈，不适合高并发
有序性好	分库分表后很难保证全局唯一性

---

📊 七、方案选型建议

业务场景	推荐方案
高并发场景（如订单系统）	Snowflake
多业务统一 ID 生成服务	Leaf Segment
简单项目快速开发	Redis
单体系统、轻量 CRUD 应用	数据库自增

---

🔐 八、踩坑记录 & 实战建议

• Snowflake 要处理时钟回拨问题，建议部署 NTP 校时服务
• Leaf Segment 初始号段需设置足够大，避免频繁 DB 请求
• Redis 方案注意集群容灾和持久化配置
• MySQL 自增主键不要用于分布式场景的外部 ID 暴露

---

📝 九、总结

属性	Snowflake	Leaf Segment	Redis	DB 自增
性能	⭐⭐⭐⭐	⭐⭐	⭐⭐⭐	⭐
实现复杂度	中	高	低	极低
趋势递增	✅	✅	✅	✅
分布式支持	✅	✅	✅	❌

结语：每种 ID 方案都有其应用场景，不存在“一招通吃”的方式，结合系统规模、团队技术栈、业务可用性要求，合理选择，避免踩坑。

---