分布式ID生成方式及优缺点详解

🤟致敬读者

• 🟩感谢阅读🟦笑口常开🟪生日快乐⬛早点睡觉

📘博主相关

• 🟧博主信息🟨博客首页🟫专栏推荐🟥活动信息

---

文章目录

• 分布式ID生成方式及优缺点详解
• • • [⚙️ 一、UUID（Universally Unique Identifier）](#⚙️ 一、UUID（Universally Unique Identifier）)
    • [⬆️ 二、数据库自增ID](#⬆️ 二、数据库自增ID)
    • [🔄 三、数据库集群模式](#🔄 三、数据库集群模式)
    • [📦 四、数据库号段模式（Segment）](#📦 四、数据库号段模式（Segment）)
    • [🧠 五、Redis生成](#🧠 五、Redis生成)
    • [❄️ 六、Snowflake算法](#❄️ 六、Snowflake算法)
    • [🏢 七、企业级优化方案](#🏢 七、企业级优化方案)
    • [💎 方案对比总结表](#💎 方案对比总结表)
    • [💡 选型建议](#💡 选型建议)

---

📃文章前言

• 🔷文章均为学习工作中整理的笔记。
• 🔶如有错误请指正，共同学习进步。

---

分布式ID生成方式及优缺点详解

在分布式系统中生成全局唯一ID是保证数据一致性和系统可扩展性的关键技术。不同的生成策略各有其适用场景和优缺点，下面从面试角度详解7种主流方案，并附对比总结表：

⚙️ 一、UUID（Universally Unique Identifier）

• 原理 ：基于MAC地址、时间戳和随机数生成128位（32位16进制）字符串，如 05cb2d06-1aca-4121-acb0-dfafce04dc46。
• 优点 ：
  • 实现简单（UUID.randomUUID().toString()）💻
  • 无需中心节点，无网络开销
  • 全球唯一性保证（理论重复概率极低）
• 缺点 ：
  • 无序存储导致数据库索引性能下降（B+树频繁分裂）
  • 长度过长（36字节），浪费存储和带宽
  • 无业务含义，可读性差
• 适用场景：临时令牌、低并发日志ID

⬆️ 二、数据库自增ID

• 原理 ：单点数据库表使用AUTO_INCREMENT，通过REPLACE INTO或INSERT获取自增ID。
• 优点 ：
  • 严格递增，利于索引和范围查询
  • 数字类型存储高效（如BIGINT仅8字节）
• 缺点 ：
  • 单点故障风险（数据库宕机则ID服务中断）
  • 性能瓶颈（QPS通常低于2K）
  • 分库分表时需额外路由逻辑
• 适用场景：小型单体应用

🔄 三、数据库集群模式

• 原理：多数据库实例设置错位步长（如实例1步长2起始1 → 1,3,5；实例2步长2起始2 → 2,4,6）。
• 优点：缓解单点问题
• 缺点 ：
  • 扩容需手动调整步长（易导致ID冲突）
  • 并发能力仍受单库限制
  • 维护成本高（需停机修改配置）
• 适用场景：低并发多活架构

📦 四、数据库号段模式（Segment）

• 原理 ：批量申请ID段（如1~1000）缓存在服务内存，用尽后更新数据库max_id。

  UPDATE id_generator SET max_id = max_id + step, version = version + 1 
  WHERE biz_type = 'order' AND version = @old_version

• 优点 ：

  • 数据库压力小（1次查询获取多个ID）
  • 性能高（本地内存分配）
  • 支持乐观锁防并发冲突

• 缺点 ：

  • 服务重启可能导致号段丢失（需持久化未用ID）
  • 实现复杂度较高

• 开源实现：美团Leaf-Segment

🧠 五、Redis生成

• 原理 ：利用INCR或INCRBY原子操作生成连续ID。

  127.0.0.1:6379> INCR global_order_id
  (integer) 1001

• 优点 ：

  • 高性能（内存操作，QPS可达10万+）
  • ID自然递增

• 缺点 ：

  • 持久化风险：RDB快照可能丢失数据（需AOF+每秒刷盘）
  • 集群模式下需预分配范围（类似数据库步长）
  • 增加系统复杂度

• 适用场景：已有Redis基础设施的中高并发系统

❄️ 六、Snowflake算法

• 原理 ：64位ID = 1位符号(0) + 41位时间戳（毫秒） + 10位机器ID + 12位序列号。
  • 单机每秒可生成409.6万个ID（理论值）
• 优点 ：
  • 无中心节点，高性能
  • 时间戳保证趋势递增
  • 数字类型存储友好（Long类型）
• 缺点 ：
  • 时钟回拨问题：系统时间倒退会导致ID重复（需暂停服务或时钟同步）
  • 机器ID需手动分配（ZooKeeper协调）
• 解决方案 ：
  • 美团Leaf-Snowflake：引入ZooKeeper管理机器ID
  • 百度UidGenerator：采用环形缓冲预生成ID

🏢 七、企业级优化方案

1. 美团Leaf ：
   • 融合号段模式和Snowflake
   • 支持双模式切换，解决时钟回拨
2. 滴滴TinyID ：
   • 基于号段模式支持多数据库源
   • 号段预加载（使用20%时异步拉取新号段）
3. 百度UidGenerator ：
   • 修改Snowflake位分配（28秒级时间 + 22位机器ID）
   • 通过RingBuffer提升并发至600万QPS

💎 方案对比总结表

生成方式	全局唯一	有序性	可读性	性能	缺点
UUID	✅	❌	❌	⭐⭐⭐⭐	无序、存储大
数据库自增ID	✅（单点）	✅	✅	⭐	单点故障、低并发
数据库集群	✅	✅	✅	⭐⭐	扩容复杂
数据库号段	✅	✅	✅	⭐⭐⭐⭐	实现稍复杂
Redis	✅	✅	✅	⭐⭐⭐⭐⭐	持久化风险
Snowflake	✅	⚡趋势递增	✅	⭐⭐⭐⭐⭐	时钟回拨问题
Leaf/UidGenerator	✅	✅	✅	⭐⭐⭐⭐⭐	依赖外部协调（如ZK）

💡 选型建议

• 低并发简单系统：UUID或数据库自增ID
• 高并发金融场景：数据库号段模式（Leaf-Segment）
• 超高性能需求：Snowflake变种（Leaf-Snowflake/UidGenerator）
• 强顺序要求：Redis或数据库自增ID

⚠️ 关键面试点：Snowflake的时钟回拨解决需结合具体实现（如等待时钟追平、ZK协调）；号段模式的版本号更新是乐观锁核心。实际选型需综合系统规模、运维成本和技术栈一致性评估。

---

📜文末寄语

• 🟠关注我，获取更多内容。
• 🟡技术动态、实战教程、问题解决方案等内容持续更新中。
• 🟢《全栈知识库》技术交流和分享社区，集结全栈各领域开发者，期待你的加入。
• 🔵加入开发者的《专属社群》，分享交流，技术之路不再孤独，一起变强。
• 🟣点击下方名片获取更多内容🍭🍭🍭👇

---