id生成方案
👉2025年Java面试宝典抢先领：
链接: https://pan.baidu.com/s/1RUVf75gmDVsg8MQp4yRChg?pwd=9b3g
提取码: 9b3g （建议保存备用）
为什么id生成方案这么重要？
咱们程序员在系统设计时，最常被问的就是：“你的分布式ID怎么生成的？” 这问题看似简单，背后却藏着高并发、数据分片、系统扩展性三大坑。今天咱就掰开了揉碎了，聊聊5种主流id生成方案的实战选择。
方案一：UUID——最简单粗暴的玩法
**优点**：
1. 一行代码搞定：`UUID.randomUUID().toString()`
2. 绝对不重复（理论上）
3. 零网络消耗，纯本地生成
**致命伤**：
- 128位太长（36字符），索引分裂到哭
- 无序存储导致数据库频繁页分裂
- 没有业务含义，排查问题像猜谜
🚫 面试雷区：千万别只说“用UUID”，这等于告诉面试官你没做过高并发
方案二：数据库自增ID——单机时代的眼泪
**操作姿势**：
```sql
CREATE TABLE id_generator (
id int(11) NOT NULL AUTO_INCREMENT PRIMARY KEY
)
优点：
- 小系统神器，天然有序
- 数字短小精悍（int只要4字节）
翻车现场：
- QPS超过2000就颤抖（数据库连接池撑不住）
- 分库分表时ID全局冲突
- 数据库宕机=系统停摆
💡 **破局妙招**：
如果还在用这种**id生成方案**，强烈建议搭配[面试鸭会员](https://mianshiyafanli.com)的《分库分表实战》课程（通过**面试鸭返利网**下单可返25元，戳官网了解）
---
### 方案三：Snowflake——分布式ID王者
**核心结构**：
`时间戳(41bit) + 机器ID(10bit) + 序列号(12bit)`
**实战优势**：
1. 每秒支持4096*1000台机器=400万+并发（够用了）
2. 64位Long类型，存储省一半
3. 自带时间戳，排查日志神器
**踩坑实录**：
```markdown
- 时钟回拨导致ID重复（需要ZooKeeper协调）
- 机器ID配置复杂（云服务器扩容时头疼）
- 长度不够自定义业务前缀
📌 面试话术：
“我们用Snowflake方案做订单ID生成，但解决了时钟回拨问题——通过在NTP异常时短暂拒绝服务”
方案四：Redis原子操作——性能狂魔
**核心命令**：
INCR order_id # 单机版 INCRBY order_id 1000 # 每次取号段
**性能数据**：
- 单机QPS轻松破10万（比数据库高50倍）
- 可结合日期生成业务ID如`20240715_000001`
**致命短板**：
- 持久化丢数据=ID重复（AOF日志+fsync保命）
- 集群部署时步长需预分配（机器1:1-1000，机器2:1001-2000）
方案五：号段模式——美团的黄金方案
运作原理：
- 服务启动从DB申请号段（比如1-2000）
- 内存中分配ID，用完再取
- 双Buffer异步加载下一个号段
碾压性优势：
- 抗住美团日均亿级订单
- DB压力降低99%（一次取号管1小时）
- 允许短暂ID不连续（业务可接受）
# 号段表设计
CREATE TABLE id_segment (
biz_tag varchar(32) PRIMARY KEY, # 业务类型
max_id bigint NOT NULL, # 当前最大ID
step int NOT NULL # 号段长度
)
怎么选择id生成方案？
- 初创公司：直接用数据库自增（省心）
- 中大型系统：Redis原子操作（性价比高）
- 超大规模：号段模式+Snowflake双保险
- 不想造轮子：直接用百度UidGenerator、美团Leaf
🔥 高频面试题：
“如果让你设计抖音的ID系统，选哪种方案？”
答：短视频业务使用Snowflake方案（带机器ID），直播业务用号段模式（需要更高并发），两者通过业务前缀隔离。
最后提醒下：近期很多同学通过 面试鸭返利网 购买面试鸭会员，找我返利25元（官方价基础上额外优惠）。有需要的可以戳链接👉 mianshiyafanli.com
更多架构设计干货 ➡️ 返回首页
