银星皓月做了几年后端，分布式ID这话题几乎绕不开。订单号、消息ID、日志追踪ID、优惠券编号，只要系统一拆成多节点，一个全局唯一的ID生成方案就得提上日程。标题看着简单，真选型的时候坑却不少：有人图省事直接用UUID，结果索引膨胀到怀疑人生；有人抄了个雪花算法，时钟一回调就冒出重复ID；还有人拿Redis当万能药，持久化策略没想清楚就上了线，重启之后直接蒙圈。所以我想把这几年在分布式ID上踩过的坑和用过的方案整理一遍，给正在做分布式架构、微服务改造，或者面试前想系统梳理这块知识的同学一份能直接参考的清单。
1. 为什么分布式系统里ID成了一个问题
1.1 单机自增ID的风光与局限
单机时代，一把 auto_increment 就能解决所有问题。MySQL 的自增主键简单可靠、天生有序，还不用业务代码操心，新插入一行拿到一个不重复的整数就可以了。但在分布式架构下，这个方案立刻变得尴尬。假设订单表拆成了 16 个库，每个库都从 1 开始自增，第一单库1生成订单号1，第一单库2也生成订单号1，到了汇总层一看，两个订单号长得一模一样，完全没法定位。
有人会说，那就给每个库设置不同的初始值和步长。比如双库场景，库1 从 1 开始每次加 2，库2 从 2 开始每次加 2，这样两个库的ID看似不冲突。但问题在于扩容：你原本只有 2 个库，后来业务量上来要扩成 4 个，就必须重新调整每个库的初始值和步长，而且已经生成过的ID没法回退。线上执行这种变更，谁做谁知道，改错一步就是主键冲突和脏数据横飞。所以 "数据库自增ID + 分库分表" 只能作为过渡方案，不能当长期分布式ID方案用。
1.2 分布式ID的基本要求
判断一个分布式ID方案好不好，不能只看"全局唯一"这一个指标，生产环境里通常还要满足几个硬性条件。
首先是全局唯一，不用展开。其次是趋势递增或单调递增。为什么强调趋势递增？因为很多系统用ID做主键，而MySQL InnoDB的聚簇索引是按主键顺序物理排列的。如果ID完全随机，插入时B+树节点会频繁页分裂，产生大量随机IO，写入性能直线下降。反过来，ID趋势递增时，新记录基本追加在末尾，写入效率高得多。第三是高可用低延迟，ID生成服务不能成为瓶颈，一旦它挂了，整个写入链路就全部卡死。第四是能够承载一定的业务语义，比如从ID里能读出生成时间、机器信息，方便排查问题。最后看安全合规，对外暴露的ID不能有明显的规律性，否则别人能通过订单号推测你的订单量，甚至使用遍历方式爬数据。
这些要求往往互相冲突。趋势递增和不可猜测就不太好同时满足，UUID完全随机但不可猜测，雪花ID趋势递增但容易被猜测。因此实际落地时，没有银弹，只有"根据业务场景做取舍"。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 常见的分布式ID生成方案横向对比
2.1 UUID/ULID：最简单但别乱用
UUID是很多新手的首选，无他，代码里一行UUID.randomUUID().toString()就完事，本地生成，不需要任何网络请求，性能无限大。但把UUID直接塞进数据库做主键，往往是最糟糕的体验。UUID是128位，转成字符串有36个字符，存储空间比bigint大得多；再加上它完全无序，作为InnoDB主键时索引分裂严重，数据量一旦上千万，写入性能肉眼可见地下降。
如果一定要用UUID，可以做个折中：把UUID二进制化，存成BINARY(16)，省掉横杠和字符编码开销；或者给UUID额外加一个雪花ID作为业务主键，把UUID降级为业务流水号、追溯ID。像分布式追踪里的traceId，通常用UUID或Ulid就够，因为它们不需要参与数据库主键排序，只承担链路关联职责。ULID比UUID强的地方在于它带48位时间戳，有序且能按时间排序，但长度并未缩小多少，适合对可排序有要求但不需要短ID的场景。
2.2 数据库自增与号段模式
数据库自增虽然是单机时代的产物，但分布式场景下它升级成了"号段模式"，目前仍在大量中间件中使用。号段模式的核心思路是：与其每次生成ID都访问数据库，不如一次从数据库取一批ID放内存里慢慢用，用完了再去取一批。
具体实现不复杂。数据库里建一张发号表，字段大致是biz_tag（业务标识）、max_id（当前已发放的最大ID）、step（步长）、version（乐观锁版本号）。每次取号时执行类似下面的SQL：
sql复制UPDATE id_allocator
SET max_id = max_id + step, version = version + 1
WHERE biz_tag = 'order' AND version = #{version};
更新成功表示拿到了这一段ID，然后把max_id返回给应用层，应用层在内存里从max_id - step + 1一直发到max_id。乐观锁能避免多个实例同时更新时互相覆盖，保证同一个biz_tag下不会有重复号段。
这个方案的优点很明显：ID是整型的、趋势递增的，对数据库索引非常友好；可以通过调整step来控制数据库访问频率，批量取号后性能也不错。缺点是应用层重启时，内存里还没用完的号段会作废，造成ID空洞；数据库成了单点，一旦发号库不可用，所有业务都会受影响。所以要给发号库做高可用，并且把不同业务的biz_tag分开管理，防止一个业务突增把号段耗尽连累其他业务。
2.3 Redis INCR/INCRBY生成ID
Redis的INCR命令是原子操作，利用单线程特性可以很容易拿到全局递增的整数。很多系统会拼一个日期前缀，比如20260214 + 自增值，既能看出哪天生成的，又保持趋势递增。实现起来很轻量，两三行Redis代码就能搞定。
但依赖Redis做ID生成，最怕的是持久化问题。Redis默认RDB快照是有丢失窗口的，主库宕机后即使切换了从库，已经生成但没来得及刷盘的ID可能丢失，恢复后INCR又从头开始，线上就有可能出现重复ID。如果开AOF，也必须把刷盘策略设为everysec甚至always，否则同样有丢失风险。可always的写性能代价又很大，有点得不偿失。所以Redis方案更适合"ID丢了可以接受，但绝不能重复"的场景，比如非核心的日志ID、埋点ID、临时会话ID。真要拿它给订单生成主键，建议别这么干。
2.4 雪花算法Snowflake及其变种
雪花算法(Snowflake)是Twitter开源的一套分布式ID生成算法，也是目前国内互联网公司用得最广的方案。它生成的ID是一个64位long型，核心思想是把时间戳、机器ID、序列号压缩到一个整数里。只要时间戳不重复、机器ID不冲突、同一毫秒内序列号不超上限，生成的ID就是全局唯一的。
雪花ID天然具备趋势递增的特性，同时还能从ID中解出生成时间，排查问题时非常有用。不依赖数据库和Redis，纯内存计算，单机每秒能生成几十万个ID，性能和可用性都很高。它也不是没有缺点，最典型的就是时钟回拨问题：如果服务器从NTP服务器同步时间时发生时间回拨，上一毫秒已经生成过的序列号在当前时间下可能再次出现，就会导致ID重复。另外机器ID需要人工分配，分配不好也容易出问题。后面我会专门用一整节拆解雪花算法的细节。
2.5 基于ZooKeeper/etcd的序列生成
还有一种思路是借助ZooKeeper或etcd这类分布式协调组件来分配序列号。比如利用ZooKeeper每个数据节点的version编号，或者通过zkClient.getData().getStat().getVersion()实现一个全局递增序号。优点是能严格保证顺序，适合对全局单调递增有强迫症的场景；缺点是性能天花板很低，一次生成一个序号就要一次分布式一致性协议交互，延迟和吞吐完全没法跟雪花算法、号段模式相比。
而且引入ZK/etcd本身是有运维成本的，集群规模一大，组件自身也是要重点保护的对象。如果仅仅为了生成ID就引入这样一个重量级组件，不太划算。更多时候，ZK是用来做雪花算法的机器ID分配器，而不是直接做发号器。
2.6 方案对比速查表
| 方案 | 全局唯一 | 趋势递增 | 性能 | 可用性 | 依赖组件 | 典型适用场景 |
|---|---|---|---|---|---|---|
| UUID/ULID | 高 | UUID否/ULID是 | 极高 | 无需依赖 | 无 | 链路追踪、临时文件名、非核心数据 |
| 数据库自增 | 单库高/分库需改造 | 是 | 低 | 依赖DB | MySQL等 | 单机、低并发内部系统 |
| 号段模式 | 高 | 是 | 中高 | 依赖DB，需高可用 | DB | 订单号、业务主键等核心数据 |
| Redis INCR | 高 | 是 | 高 | 依赖Redis持久化 | Redis | 可容忍ID空洞的流水号 |
| 雪花算法 | 高（需处理回拨） | 趋势递增 | 高 | 无外部依赖，需本机时钟 | 无/弱依赖 | 高并发核心业务，日志、消息、订单均可 |
| ZooKeeper/etcd | 高 | 严格递增 | 低 | 依赖ZK/etcd | ZK/etcd | 对顺序一致性要求极高的低频场景 |
3. 雪花算法：原理拆解与实战参数设计
3.1 雪花ID的位段结构
雪花算法的核心就是把一整段二进制位按业务需求切分。经典的69位分配是：第1位是符号位，固定为0；接下来41位是毫秒级时间戳；再接下来10位是机器ID；最后12位是同一毫秒内的序列号。整个加起来正好64位，可以用Java的long类型直接装下。
41位时间戳能表示约69年的时间，这里的时间基准不是Unix纪元1970-01-01，而是可以自定义一个起始时间，比如2020-01-01 00:00:00。自定义纪元的好处是可以在同样长度里容纳更多未来年限，也能让生成的ID在数值上更小，不浪费位宽。
机器ID的10位，可以进一步拆成5位数据中心ID和5位工作节点ID，这样在最大规模下支持32个机房、每个机房32个节点，总共1024个节点。如果你的业务没有机房维度，10位全部当作工作节点ID也行，支持1024个节点。序列号12位，意味着同一毫秒内最多能生成4096个ID，如果并发量超过这个数，算法必须自旋等到下一毫秒再继续生成。
在实现层面，序列号通常用位运算来保证循环和溢出判断。伪代码大概是：
java复制long sequence = (sequence + 1) & 4095; // 4095 = (1 << 12) - 1
if (sequence == 0) {
// 说明当前毫秒内的4096个序号已经用完，进入下一毫秒等待
}
这里的& 4095是一个巧妙的取模操作，当序列号累加到4096时，按位与后自动归零，同时判断是否归零来驱动时间戳前进。很多初学者会写成if (++sequence > 4095)，也能用，但位运算更贴近位段设计的本意，性能也更好。
3.2 时钟回拨问题如何应对
时钟回拨是雪花算法最大的敌人。服务器默认开启NTP时间同步，一旦网络抖动或本地时钟漂移，NTP服务有可能把系统时间"拨回去"。此时如果当前毫秒时间戳小于上一次生成ID时记录的时间戳，再用这个时间戳生成ID，就极有可能和之前已生成的ID重复。
先说最保守的方案：检测到当前时间小于上次生成时间时，直接抛异常拒绝服务。这种做法确保了安全性，代价是服务短暂不可用。如果回拨幅度是几毫秒，等待时间还能接受；但如果回拨了几百毫秒甚至几秒，这个等待会拖垮接口响应。
稍微友好一些的做法是"等待追上"。记录上一次生成ID的时间戳lastTimestamp，检测到回拨后，让当前线程自旋等待，直到系统时间追上lastTimestamp再继续生成。因为时间永远是前进的，最多需要等一个回拨周期。这种方案适合回拨幅度小、频率低的场景。
更复杂的方案是"借用未来时间"。维护一个缓存中的最大时间戳，假设上次生成ID时已经用到了时间戳T，现在系统时间回拨到T-1000，仍然允许基于T+1的时间戳生成新的ID，但同时记录这是一个"未来时间"。后面所有生成的ID时间戳都不要小于这个最大值，直到系统时间真正到达这个未来时间为止。美团Leaf-snowflake就采用了类似思路，能在秒级回拨下保持服务可用。
行业里还有一种做法是"扩展序列号位"。既然时间戳回拨会导致重复，那就减少对时间戳的依赖，把机器ID位或序列号位变宽。比如有些自研方案会把64位改成"时间戳+机器ID+随机数种子"，或者使用数据库记录上一毫秒最大序号，恢复时从最大序号继续往后排。但要清楚，任何方案只能降低回拨影响，无法彻底消除，物理世界的时间回拨无法靠算法根除，只能在部署层面尽量减少。
3.3 机器ID分配与高可用部署
机器ID分配看起来简单，实际上特别容易翻车。有人干脆用服务器IP的哈希值或MAC地址来生成机器ID，结果要么冲突，要么明明换机器了还沿用旧ID，最后后台报警一堆重复主键。
最靠谱的分配方式是集中管理。用ZooKeeper做一个持久顺序节点，每个服务实例启动时创建一个临时顺序节点，拿到返回的序号作为机器ID。实例退出时临时节点自动消失，机器ID释放。但这里要注意，如果你直接拿顺序节点序号当机器ID，实例重启后拿到的序号可能不同，导致曾经用旧机器ID生成过的数据无法按机器维度追溯。所以更好的办法是用一个持久节点保存实例的唯一标识，比如worker-{ip}-{port}，只有新实例第一次注册时创建持久节点，之后重启直接获取既有节点上的序号，保证机器ID不变。
机器ID分配好之后，高可用部署就比较简单了。将发号服务独立部署为无状态服务，每个节点分配不同的机器ID，前端用负载均衡打到任意节点即可。由于雪花算法本身不依赖外部存储，只要节点的系统时间大致准确，多个节点同时生成也不会冲突。实际部署时，建议给发号服务所在的宿主机关闭NTP自动回拨，改为定期手动调整，或者使用高精度的PTP时间同步服务，把时钟回拨概率降到最低。
4. 生产级方案落地：美团Leaf与百度UidGenerator
4.1 Leaf-segment号段模式的实现思路
美团的开源项目Leaf把号段模式做成了可以直接落地的产品。Leaf-segment模块的核心思路就是前面提到的号段模式，但它在工程实现上多了两个很关键的设计。
第一是双buffer预加载。Leaf在内存里维护两个号段，当前号段消耗到比如segment * 0.75的时候，后台异步线程立刻去数据库加载下一个号段到另一个buffer里。这样即使业务高峰期当前号段突然耗尽，也不会发生"临时访问数据库"的阻塞等待。两个buffer交替使用，让取号服务始终有可用号码。
第二是数据库表设计得贴近实际。表里每个biz_tag一行记录，不同业务之间完全隔离，互相不会影响。比如订单业务突然做秒杀，把号段消耗速度拉满，也不会把优惠券业务的号段池拖垮。同时version字段配合乐观锁更新，比悲观锁性能好很多，避免每条更新都锁行。
从运维角度看，Leaf还提供了HTTP接口，业务系统可以用一行HTTP请求换取一个或多个ID，也支持通过LeafController批量获取。如果不想再引入一个服务，直接把号段模式的核心逻辑内嵌到自己的微服务基座里也是可以的，很多公司就是这么干的。
4.2 Leaf-snowflake模式的高可用
Leaf不仅仅只有号段模式，它还提供了一种基于雪花算法的实现，叫Leaf-snowflake。它解决了雪花算法落地时最头疼的两个工程问题：机器ID分配和时钟回拨容忍。
Leaf-snowflake在启动时向ZooKeeper注册一个持久顺序节点，取得全局唯一的workerId。因为每个服务实例都对应一个持久节点，重启实例时并没有重新创建节点，而是去拿已有节点的data，所以workerId能保持稳定，不会因为重启而漂移。同时它会启动一个定时任务，定期上报自身的时间戳到ZooKeeper。如果某个节点发生时钟回拨，ZooKeeper上能检测到"节点时间戳小于上报过的时间戳"，此时该节点会被标识为状态异常，不再对外提供ID生成服务。
在回拨容忍方面，Leaf-snowflake的策略是：如果回拨小于某个阈值（比如5毫秒），就在内存里等待直到系统时间追上；如果回拨过大，则拒绝服务并告警，让运维介入。这个"小回拨等待、大回拨熔断"的思路，比无脑抛异常要高一个层次。
4.3 UidGenerator的BitsAllocator与自旋
百度开源项目UidGenerator同样借鉴了雪花算法，但它把位段分配做成了高度可配置的BitsAllocator。默认分配是1 + 28 + 22 + 13，分别对应符号位、秒级时间戳、workerId和序列号。为什么时间戳只能显示28位？因为它把时间单位从毫秒降到了秒，这样同样长度的比特位能表示的时间跨度更长。代价是同一秒内需要更大的序列号来支撑并发，于是序列号用了13位，每秒能生成8192个ID，如果还不够，就通过自旋等到下一秒。
UidGenerator更加特色的地方在于它用环形缓冲（RingBuffer）缓存待生成的UID。它采用一个数组预先生成一批ID，通过生产者-消费者模式提供出去。消费者的取号请求在本地内存完成，不涉及网络IO，性能非常可观。同时它在workerId管理上也是通过数据库表自增分配，启动时插入一条记录获取workerId，并在运行期间做心跳续约。
不过要提醒一句，UidGenerator虽然性能高，但它的默认配置偏向秒级低延时场景，如果你希望生成的ID里能直观看到毫秒时间，需要自己重新调整位段分配，并且估算好当前业务的QPS峰值，否则序列号位不够就会频繁自旋等待。位段设计没有标准答案，完全看你的时间精度与并发规模需求。
5. 选型建议与避坑实录
5.1 业务场景决定方案
很多群里经常有人问"分布式ID到底选哪个"，下面的回答通常是"看业务"。这四个字听着不痛不痒，实际确实如此。这里我给出一个更可操作的选型思路：先看ID是否作为数据库主键，再看是否能容忍ID空洞，再看是否需要从ID解出业务信息。
如果ID要作为数据库主键，请直接排除UUID方案，优先考虑雪花算法或号段模式，保证趋势递增，避免索引页分裂。如果业务对ID的连续性没有硬性要求，接受偶尔的空洞（比如并发插入失败、事务回滚产生的断号），那号段模式和雪花都可以。如果业务要求ID严格单调递增，比如用于排序展示的流水号，那最好用数据库强一致序列，或者基于Redis的原子自增，但要做好组件高可用。
从团队成本角度看，没有太多人力维护基础设施的话，建议优先使用雪花算法变种，启动成本最低，一个公共组件类就能搞定。如果公司已经部署了ZK或etcd，可以考虑Leaf-snowflake。如果核心业务量极大、又有专门的DBA团队维护发号库，那Leaf-segment的号段模式是稳的选择。
5.2 实践中容易踩的坑
我见过不少项目最后出问题，都不是方案本身不行，而是落地细节没处理好。第一个坑是UUID主键拖垮数据库，这个前面已经反复强调过，不是危言耸听。如果历史表已经用了UUID，迁移时可以把UUID转换成BINARY(16)存储，或者新增一个雪花ID列作为隐藏主键，逐步切换。
第二个坑是雪花算法的自定义纪元没有设置，导致生成的ID前几位时间值特别大，看起来像负数。实际上因为符号位固定为0，不太会出现负数，但如果你把64位结果打印成带符号long，而时间戳用了1970基准，到2038年前后就会超出Integer.MAX_VALUE的范围，一些老系统转int就炸了。所以使用long类型，别随手转int。
第三个坑是机器ID在测试环境没管，单机自测没问题，一上多节点压测就大量重复。解决思路有两个：要么强制规定必须通过配置中心下发机器ID，没有配置就启动失败；要么启动时利用Redis/数据库/ZK做一次workerId注册校验，检测到重复就拒绝启动。
第四个坑是滥用Redis生成ID的场景没有考虑持久化。Redis重启后INCR重新从0开始，如果旧数据里已经有ID，新生成的ID就可能重复。真要拿Redis当发号器，建议使用INCRBY并以日期为key，同时开启AOF，并配置appendfsync为everysec，在性能和可靠性之间找平衡。
5.3 分布式ID与分布式锁的关系
搜索热词里分布式锁频繁出现，两者确实经常被拿到一起聊，但要搞清楚它们是不同的问题域。分布式锁解决的是"多个节点互斥访问同一资源"的问题，典型场景包括订单并发扣减库存、定时任务防止重复执行。分布式ID解决的是"多个节点生成全局唯一标识"的问题。两者不冲突，但也不应该互相替代。
有些项目非要用Redis分布式锁包裹数据库自增来生成ID，先获取锁，再向数据库插入数据拿自增ID，然后释放锁。这么做不但性能极差，还可能因为锁超时、锁误删导致ID生成被严重延迟。发号器设计的第一原则是高可用、低延迟，所以它应该是无锁的，或者只在短时间内持有内存级别的锁。雪花ID用机器ID和序列号天然规避了互斥，号段模式用乐观锁替代悲观锁，都是为了避免分布式锁带来的复杂度。
5.4 一份可以直接参考的落地建议
以我自己的偏好，如果从零开始做一个新系统，我会分两层处理。核心业务主键，比如订单号、支付流水号、用户ID，优先用号段模式或者Leaf-segment，因为这类ID要入库、要展示给外部、要对数据库索引友好，号段模式的整型、趋势递增、可控性强。高并发日志型ID、消息ID、链路追踪ID，用雪花ID或ULID，因为它们不一定要入库做主键，更多是快速生成、全局唯一、便于排查。
同时，发号服务最好独立成模块，不要在每个业务方法里复制一份ID生成代码。统一入口之后，后续换方案、加监控、做限流都方便很多。发号服务也要有基本的容器监控，关注生成耗时、号段剩余量、时钟偏移量这些指标，别等到线上出问题才去看。
我个人在实际操作中的体会是，分布式ID方案没有一步到位的完美解，每个方案都是一套取舍。快速迭代的项目先用UUID或者简单雪花撑住，等数据量上来了再引入更重的号段服务，完全可行。关键是每个方案潜在的坑要在心里有数：用了UUID就早点规划主键迁移，用了雪花就一定要处理时钟回拨，用了Redis就先把持久化策略想清楚。后面再遇到"分布式ID怎么选"这类问题，先问清楚业务场景、并发量级、运维成本，答案自然就出来了。