分布式唯一id生成方案

👉2025年Java面试宝典抢先领取：
百度网盘链接
提取码：9b3g
（建议保存，面试高频考点全覆盖！）

在分布式系统中生成全局唯一ID，是面试中高频的架构设计题。今天我们就从实战角度拆解几种主流方案，帮你轻松拿下面试！

为什么需要分布式唯一ID？

当数据库分库分表后，自增主键会重复。此时需要满足：

全局唯一（核心要求）
趋势递增（优化索引性能）
高可用（QPS 10万+）
长度适中（减少存储开销）

常见方案及面试坑点

方案一：UUID

#️⃣ 实现：`UUID.randomUUID().toString()`  
✅ 优点：简单、本地生成无网络消耗  
❌ 致命缺点：  
   - 无序导致索引分裂（插入性能差）  
   - 字符串存储占36字节（MySQL推荐用整型主键）  
💡 结论：**不推荐**作为数据库主键

UUID结构示意图

方案二：数据库自增ID

#️⃣ 实现：单独创建ID生成表  
```sql
REPLACE INTO id_generator (biz) VALUES ('order');
SELECT LAST_INSERT_ID();

✅ 优点：利用数据库原子性保证唯一
❌ 缺陷：

DB单点故障（需主从切换）
性能瓶颈（QPS难破万）
💡 优化方向：号段模式（Leaf-Segment）
每次批量获取ID段（如1~1000）
客户端内存分配，降低DB压力


---

#### 方案三：Redis生成
```markdown
#️⃣ 实现：`INCR` 命令原子递增  
✅ 优点：性能强悍（单机10W+ QPS）  
⚠️ 风险点：  
   - 持久化丢失可能导致ID重复（AOF持久化可缓解）  
   - 集群环境下需要维护步长（如实例1生成奇数，实例2生成偶数）

方案四：Snowflake算法（面试最爱问！）

#️⃣ 核心结构（64bit）：  
0 | 41位时间戳 | 10位机器ID | 12位序列号  
✅ 优势：  
   - 本地生成无网络IO  
   - 整型存储+趋势递增  
🔥 致命问题：**时钟回拨**  
   - 解决方案：  
     1. 等待时钟追上（业务停滞风险）  
     2. 扩展位记录回拨次数

Snowflake算法结构图

方案五：美团Leaf方案

#️⃣ 双引擎设计：  
1. **Leaf-Segment**：  
   - 预分配号段（如：1000~2000）  
   - 双Buffer异步加载  
2. **Leaf-Snowflake**：  
   - Zookeeper分配WorkerID  
   - 时钟回拨时自动切换节点  
📈 性能：单机TP 10w+

面试回答技巧

当被要求设计分布式ID时，建议按以下逻辑分层回答：

业务场景：
“根据我们订单量预估（如日订单100万），需要支撑5万QPS的ID生成”
方案选型：
“优先考虑Snowflake变种，因其无网络消耗且性能达标。若机器规模超过1024台（10位机器ID上限），改用Leaf-Segment”
容灾设计：
“针对时钟回拨，方案中需增加本地时钟监控，并设置异常熔断策略”

⚠️ 避坑提示：不要只说“用Snowflake”！必须说明如何解决时钟回拨和机器ID分配问题

进阶优化方向

压缩ID长度：从64位压缩至53位（JS安全整数）
混合时钟：结合物理时钟+逻辑时钟（如Cassandra）
业务融合：将分库分表信息嵌入ID（如末尾2位表示库号）

最后分享个福利👉 如果你正在准备面试，强烈推荐用面试鸭会员刷真题题库！
通过面试鸭返利网联系我，购买会员可额外返利25元，实测能省不少钱 💰
（悄悄说：他们的分布式题库更新超快！）

面试鸭返利网优惠活动

📌 本文关联面试题：

Snowflake的时钟回拨怎么解决？

号段模式如何保证ID不重复？

Redis生成ID如何避免持久化丢失？