只要系统开始分库分表、开始做微服务拆分，主键自增这件事就立刻变成了一个麻烦。单库单表时，数据库自增 ID 简单、有序、不重复，几乎不需要思考；可一旦数据被切到几十个分片、写请求散落在多个实例上，自增就彻底失效了——两个分片各自从 1 开始，很快就会撞号。于是”分布式 ID 生成”成了每个后端团队都要迈过的一道坎。
很多人对它的理解停留在”用雪花算法就行了”，但真正上线之后才发现：机器号分配错了会撞号，时钟回拨会让服务直接挂掉，号段耗尽时的抖动能把数据库打穿。分布式 ID 看起来只是”生成一个唯一数字”，本质却是一套要在唯一性、有序性、性能、可用性之间反复权衡的工程系统。这篇文章从三个层次，把这件事讲清楚。
第一层：唯一性是底线，但不是唯一目标
最朴素的追求当然是”全局不重复”。UUID 是很多人第一个想到的方案：本地生成、无中心依赖、性能极好，理论上碰撞概率低到可以忽略。但 UUID 有两个致命问题：一是**无序**，作为 InnoDB 的主键会让 B+ 树的插入变成随机写，页分裂频繁，写放大严重，表越大越慢；二是**太长**，字符串主键占空间，还会拖累所有二级索引。所以 UUID 适合做业务无关的幂等键，却几乎不适合做主键。
数据库自增和号段模式是另一条路子。号段模式（比如美团 Leaf 的 segment 方案）的思路是：应用启动时向数据库申请一批 ID（如 1~1000），在内存里自增发放，用完了再申请下一段。这样把”每次插入都访问数据库”变成”每 1000 次插入访问一次”，性能提升几个数量级，同时 ID 仍然单调递增，对 B+ 树友好。代价是它**依赖数据库的可用性**，而且多实例之间需要协调避免发重，通常靠 `UPDATE … SET max_id = max_id + step` 的原子性来保证。
真正的关键认知是：唯一性只是底线，在此之上你还要问三个问题——ID 是否**趋势递增**（影响写性能）、是否**可反解信息**（比如携带时间戳便于排查）、生成性能能否**扛住峰值**（秒杀场景下每秒几十万 ID）。不同的业务答案不同，选型也就不同。
第二层：雪花算法不是”复制粘贴”，是位分配设计
Snowflake（雪花算法）之所以成为事实标准，是因为它在”趋势递增”和”本地生成无中心依赖”之间取得了极好的平衡。它的结构是一个 64 位长整型：1 位符号位 + 41 位时间戳 + 10 位机器号 + 12 位序列号。41 位毫秒时间戳够用约 69 年；10 位机器号支持 1024 个节点；12 位序列号意味着同一毫秒同一节点最多生成 4096 个 ID。
这套结构看似简单，落地时的坑却几乎全在”位分配”和”时钟”上。**机器号必须全局唯一且稳定**：如果运维把同一个机器号发给了两个实例，或者容器重启后机器号漂移，撞号几乎必然发生。常见做法是用注册中心（ZooKeeper / etcd）或配置中心统一分配机器号，或者在 Kubernetes 里用 StatefulSet 的序号推算。更稳的方案是结合 Redis 的 INCR 做机器号租约，实例续租失败就停发，避免”僵尸实例”继续发号。
**时钟回拨是雪花算法的头号杀手**。如果 NTP 校时导致机器时钟往后跳，新生成的时间戳可能小于上一个 ID 的时间戳，就会产生重复 ID。工业级做法有三档：小幅回拨（几十毫秒）时**等待**时钟追上；中等回拨时**借用**未来时间戳或切换备用机器号；大幅回拨（超过阈值）时干脆**拒绝服务并告警**，宁可短暂不可用也不能发重号。所以一个健壮的雪花实现，必须显式处理时钟回拨，并在监控上暴露回拨次数。
还有一点常被忽略：**序列号在高并发下会瞬间打满**。12 位序列号只有 4096 个位置，如果某毫秒内请求超过 4096，就只能等到下一毫秒，QPS 会被硬卡在 409.6 万。如果你的业务峰值高于这个量级，就要考虑把机器号位数压缩、给序列号让位，或者干脆叠加号段做缓冲。
第三层：把 ID 服务当成一个有 SLA 的基础设施
当 ID 生成被几十个服务依赖时，它就不再是一段工具代码，而是一个**基础设施**，必须按基础设施的标准来运营。第一个动作是**降级设计**：ID 服务本身如果不可用，不能让整个业务写不进去。号段模式天然支持”预取多段缓存在本地”，服务挂了也能撑一段时间；雪花算法因为本地生成，只要机器号有效就几乎不受中心故障影响。选型时要把”中心依赖”和”可用性”这两点摆上天平。
第二个动作是**监控与容量预警**。ID 一旦发重，往往不会立刻报错，而是等到某条记录插入失败、或者数据关联错乱时才暴露，排查成本极高。所以要监控：号段剩余量、单机发号 QPS、时钟回拨次数、机器号租约状态。号段剩余量尤其重要——如果没做”双 Buffer 预加载”，号段耗尽瞬间的同步请求会形成尖刺，把数据库打穿，这是号段模式最经典的故障。
第三个动作是**ID 的可运维性**。一个好的 ID 应该能被反解：从 ID 里能读出生成时间、机器号，出问题时能快速定位是哪个节点、哪个时间窗产生的数据。雪花 ID 天生携带时间戳，这一点远胜随机 ID。同时，ID 的位数、进制、对外暴露策略也要提前定好——一旦 ID 作为订单号、用户号对外暴露，后续几乎无法更改，任何位数调整都是一次数据迁移。
结语
分布式 ID 生成是一个典型的”看起来简单、做起来极难”的领域。它没有银弹：UUID 胜在简单，败在无序；号段胜在有序高性能，败在依赖中心；雪花胜在本地生成，败在时钟与位分配。真正的工程能力，不在于背出某种算法，而在于清醒地知道自己业务需要的是哪种权衡——是需要极致性能，还是需要简单可靠？能容忍短暂不可用，还是一秒都不能停？
想清楚这些问题，再回头看那些”撞号””回拨””号段尖刺”的坑，你会发现它们都不是技术细节，而是你对系统边界的理解是否到位。把一个 ID 生成器做对，本质上就是把一个分布式系统的边界想清楚。