设计一个分布式 ID 生成系统的核心目标是在多节点环境下生成全局唯一、趋势递增、高性能、低延迟的 ID同时避免单点瓶颈。下面从「需求 → 方案 → 经典算法 → 架构设计 → 权衡」系统讲清楚。一、核心需求一个好的分布式 ID 系统通常要满足1. 全局唯一不能重复必须条件2. 高性能通常要求QPS10万 ~ 千万级单次生成 1ms3. 趋势递增可选但常见数据库索引友好如 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 类型 ID0 - 41bit 时间戳 - 5bit 数据中心 - 5bit机器ID - 12bit序列号结构如下部分位数含义符号位1固定0时间戳41毫秒级时间数据中心ID50~31机器ID50~31序列号12每毫秒内计数1. 时间戳核心排序依据支持约 69 年2^41 ms保证 ID 趋势递增2. 机器 ID分布式关键来源手动配置ZooKeeper / etcd 分配Kubernetes Pod Identity3. 序列号同毫秒并发每毫秒最多 4096 个 ID超过则等待下一毫秒四、Snowflake 生成流程if 当前时间 上次时间: sequence else: sequence 0 if sequence 4095: 等待下一毫秒 ID (timestamp shift) | (datacenterId shift) | (workerId shift) | sequence五、架构设计生产级1. 单机版 SnowflakeApp ↓ 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备用逻辑推荐使用逻辑时钟或切换 workerId2. workerId 如何分配常见方式1ZooKeeper / etcd临时节点自动释放2数据库分配worker_id table: node_ip - id3启动随机 冲突检测不推荐3. 高并发优化无锁 CAS线程本地缓存单机百万 QPS4. 跨语言支持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 压力小 缺点不严格递增依赖 DB2. Redis INCRINCR global_id优点简单缺点Redis 单点高并发瓶颈八、如何选择非常重要场景推荐方案高性能订单系统Snowflake电商订单强稳定Leaf Segment日志/追踪UUID小系统DB 自增