作为后端开发几乎每个人迟早都会面对一个问题系统拆分成多个实例或者分库分表之后原来那张表上的自增主键怎么办之前单库单表的时候AUTO_INCREMENT简直是无脑首选写起来简单性能也好还天然有序。可一旦数据量上来开始做分库分表问题立刻来了——每个库里的自增ID都会从1开始两个库各自生成了ID1001的数据合并查询一撞车直接歇菜。就算你改掉了业务联查的依赖数据的全局唯一性也完全无法保证。顺着这个方向去找方案大部分人第一眼看到的就是Snowflake雪花算法、UUID、Leaf这几个词。文章标题虽然叫“分布式ID生成”但老实讲大部分人真正缺的不是“生成ID”的代码而是搞清楚这些方案分别解决什么问题、代价是什么、在什么场景下该怎么选。这篇文章不是概念科普是我实际在项目里替换掉自增主键、对比过分布式ID方案之后整理的完整笔记。从自增为什么不行到UUID、雪花算法的原理再到业界落地的Leaf方案怎么把号段和雪花组合起来都会讲透。无论你是正在做分库分表还是单纯不想在下一个新项目里继续被自增主键坑这篇文章都值得看完。1. 自增主键的局限与分布式ID的核心需求先别急着讨论方案回到最根本的问题上为什么自增主键会在分布式场景下败下阵来以及我们期待一个“替代品”到底图的什么1.1 为什么自增主键扛不住分布式场景单机时代自增主键的好处是实打实的。数据库自己维护一个计数器每次插入自动加一。这个机制带来的收益有两点写入端简单应用层完全不用关心ID怎么来只要INSERT的时候不传主键字段数据库全权处理。天然有序后插入的数据主键必然更大对MySQL InnoDB这种聚簇索引组织表来说顺序写入就是顺序追加页分裂概率极低写入性能最稳。可是数据量上去了单表顶不住性能压力最常见的解法就是水平拆分。一张订单表拆成16个库每个库各自维护自增结果就是每个库都有ID1到N的同段数据。想靠“库号自增”拼一个全局ID又得引入额外规则业务上的复杂度也会随之上升。更麻烦的是另一个细节ID本身可能被外部系统感知。举个例子某个对外服务的接口调用方会记录返回的数据ID下次用ID查详情。如果对系统做迁移、扩容或者数据合并自增ID因为已经暴露出去不得不兼容旧值后续的ID规划就会非常憋屈。说白了自增主键解决的问题太局部。分布式场景里主键的生成者不再“只有一个数据库”而是“很多个应用实例都要自己生成、马上就能用、相互之间绝不重复”。1.2 分布式ID必须满足的六个硬指标我见过不少团队上来就拍脑袋定方案结果用了没多久就翻车。为了不犯同样的错误先梳理清楚评判一个分布式ID方案是否合格的标准。我这里总结了六条几乎覆盖了所有核心诉求指标具体含义不满足的后果全局唯一所有节点、所有时间生成的ID都不重复数据合并或跨库查询时直接冲突趋势递增后生成的ID在数值上大于先生成的ID至少趋势上如此索引写入频繁触发页分裂性能断崖式下降高性能生成过程尽可能快不依赖外部IO或依赖足够轻量高并发下接口吞吐率被拖垮高可用生成ID的服务/组件不可用时应用依然能正常工作一块单点故障整个系统全部不可用信息安全ID本身不暴露业务规模和增长量尤其是在对外场景竞对通过订单号差算出你的日订单量业务友好ID尽量短、容易传输、方便排查日志超长字符串做主键或关联会让存储成本与索引膨胀注意六条不是都要同时拉满。有的业务根本不在乎ID长不长有的业务对信息安全几乎无感有的系统允许偶尔阻塞一下。所以后面解析的UUID、Snowflake、Leaf本质上就是在做取舍——你需要哪一种特性就选哪一种妥协。2. UUID方案简单但代价不小UUID应该是很多团队最先尝试的方案理由就是简单。应用层一行代码就能生成一个全球唯一的ID不需要任何基础设施依赖。但它到底适不适合当数据库主键里面有大学问。2.1 UUID的类型与主键适配真相UUID是一个128位的二进制值通常以36字符的字符串形式展示包含4个连字符。按版本分主要就两类v1和v4。UUID v1依赖时间戳 节点标识比如网卡MAC地址生成时间上有序性。UUID v4是纯随机生成碰撞概率低到可以忽略。很多人在项目里直接用数据库自带的UUID函数比如MySQL的UUID()它其实是v1的一个变体内部包含了时间信息整体上是有序的。但问题是它并不是严格按数据库插入顺序递增。更常见的场景是应用层用UUID.randomUUID()这里面是v4。v4随机性很强拿来当主键之后每一次插入都意味着B树的大范围重排。可以使用一个生活例子来理解自增主键相当于往一摞书后面一本本加书堆得又快又整齐而UUID v4主键相当于每次从这摞书中间随机抽位置塞书进去每插一本后面的书全得挪一遍。数据库虽然不是真的“挪”数据但B树的页分裂、节点合并的操作逻辑与之差不多。页分裂多了写入性能和空间利用率都会明显下降。2.2 UUID当主键的三个真实代价除了无序UUID还有几个非常实际的问题很多人用了之后才后悔存储开销大同样是主键BIGINT占8字节UUID字符串占36字节。表越大主键索引和二级索引膨胀得越厉害。如果一张表有多个索引每个二级索引都隐式包含主键列UUID的字节数会翻倍地拖累存储。查询性能受拖累在互联网公司常见的“大宽表”场景里关联字段越多主键越宽查询时能放进内存的索引页就越少。原本一个页能装1000个索引项用UUID后可能只能装300个磁盘IO次数上升。可读性差日志里查一个ID全是一长串字符肉眼几乎没法分辨是哪台机器、哪个时间生成的。排查问题的时候心智负担会明显加大。2.3 什么场景下UUID还算合适诚实地讲UUID并非一无是处。它最大的价值是无中心化、零依赖、生成代价极低而且长度虽然长但不需要“协调者”。我见过几个还算合理的应用场景不需要参与业务关联的辅助字段比如用户行为日志的主键、埋点事件ID这类数据量大、不需要频繁联表查询UUID很适合。客户端生成的ID比如离线场景下APP端需要先生成消息ID等有网再同步到服务端UUID可以避免全局协调。多系统合并数据时的唯一标识不同系统各自维护数据UUID天然保证合并时不冲突。如果说非要强行用UUID做数据库主键有一个折中优化把UUID转成二进制BINARY(16)存储省下大量空间。但这只是缓解存储问题无序插入造成的写性能问题依旧存在。3. Snowflake雪花算法有序ID的经典方案Snowflake是这几年的绝对主流。它能做到全局唯一、趋势递增、生成过程纯内存计算、顶多偶尔依赖一下机器时钟。很多公司内部方案本质上都是雪花算法的变体或增强。3.1 64位的位段设计与空间测算雪花算法生成的ID是一个BIGINT64位整数它的结构比我第一次听到时的直觉要精巧得多。整段按位划分为四块位段位数作用符号位1固定为0保证ID为正整数时间戳差41记录相对某个起始时间的毫秒数机器ID10区分不同的应用节点最多1024台机器序列号12同一毫秒内的递增序列最多4096个这个设计最绝妙的地方在于ID数值的增长带上了时间信息。同一台机器上先生成的ID一定小于后生成的ID不同机器之间只要时间戳差不多ID的大小也大致跟随时间推进。有人会问41位时间戳到底能撑多久算一下。41位二进制最大值是2^41 - 1也就是2199023255551毫秒。换算成年数大概是69.7年。也就是说从你自定义的起始时间通常选公司成立时间或某个固定历史时间点比如2016-01-01开始这套方案能用差不多70年。对绝大多数系统完全够了。10位机器ID拆分方式也有讲究。常见的是5位数据中心ID 5位机器ID这样能支持32个机房、每机房32台机器合计1024个节点。12位序列号意味着单台机器、同一毫秒内最多生成4096个ID。换算成吞吐单台机器单毫秒4096个理论上就是每秒约409万个ID。业务系统远达不到这个量级。3.2 核心位运算与生成逻辑雪花算法的实现核心是位运算如果没用过位运算理解起来可能稍微别扭。但它的逻辑非常直观本质上就是把三块二进制数据拼接在一起// 以Java为例核心生成逻辑 long id (timestampDiff 22) | (workerId 12) | sequence;这行代码是什么意思是左移运算符。timestampDiff左移22位给机器ID和序列号腾出空间workerId左移12位给序列号腾出空间三者按位或成一个64位长整型。完整流程一般是获取当前毫秒时间戳减去起始时间得到timestampDiff。判断timestampDiff是否与上一次同一毫秒。同一毫秒sequence (sequence 1) 4095如果序列号溢出等于4095则自旋等待下一秒。不同毫秒序列号清零用当前毫秒数拼ID返回。实现要点是用synchronized或AtomicLong保证并发安全。实际生产环境中多个线程同时调生成方法必须保证序列号的原子递增。3.3 三个经典坑时间回拨、机器ID分配、序列溢出雪花算法看起来很完美但落地时坑还真不少。我挑三个最经典的逐一讲。第一个坑时钟回拨。服务器上的时钟不是绝对可靠的。NTP校时、运维手动改时间、宿主机时间漂移都可能导致当前时间比上一次生成ID的时间还要早。假设回拨了1秒序列号还在累计那生成的ID就可能和之前生成过的重复。这是50年、100年不遇但遇上了就翻车的问题。主流解决方案有几个层次简单策略发生回拨时拒绝生成ID等待时钟追上上次记录的时间再继续。适合回拨幅度很小的场景。延迟策略发现回拨先短暂休眠比如回拨5ms就睡5ms再重新尝试。适用于几毫秒的微小回拨。记录上次时间戳每个节点内存里维护“最后生成ID的时间”一旦发现当前时间小于该时间触发告警并拒绝服务。在生产环境里我的经验是必须同时做记录和拒绝不能只告警不处理。另外如果回拨幅度很大比如超过了几秒等待策略会让QPS直接归零这个影响需要通过高可用手段来兜底。第二个坑机器ID怎么分配1024个节点编号从0到1023。手工在配置文件里写死容易冲突让节点启动时去某个中心节点领取又要引入协调服务。实际项目中常见做法是小系统用IP地址后几位取模得到机器ID但IP变更时要小心冲突。大一点的公司用集中管理比如在配置中心注册启动时通过租约方式获取一段有效的机器ID。追求简单的话IP 进程启动时间戳取哈希也可以控制冲突概率但严格意义上不能保证0冲突。关键点在于机器ID是幂等的一旦某台机器用了ID5它重启后还得是5否则ID就乱套了。第三个坑序列号溢出。同一毫秒内生成超过4096个ID序列号就“溢出了”放不下了。最简单的处理方式是自旋等待到下一毫秒。如果是超高频调用可以用“全局时钟缓存 预生成”的思路在实际业务里这个场景出现概率非常小不需要过度设计。3.4 雪花算法的常见变体与增强思路因为雪花算法太经典业界围绕它做了不少版本改造。最常见的几个方向缩短ID长度把64位ID压缩成更短的形式同时保留时间有序性多见于对日志可读性要求高的场景。调整位段分配比如机器ID用得更少、序列号位数更多或者加入“业务类型标识”。引入集中式协调通过配置中心管理机器ID、监控时间回拨解决“各自为政”的问题。总体来说雪花算法用起来的经济性非常好——一个类几百行代码不需要外部依赖就把全局唯一、趋势递增、高性能、高可用全都做到位了。这也是它成为各公司自研ID生成器首选模板的根本原因。4. Leaf方案号段模式与雪花模式的工程融合聊完了经典方案再来看目前业界公认落地比较成功的开源方案——Leaf。严格来说Leaf不是一个算法而是两种生成模式的组合Segment模式号段模式和Snowflake模式雪花模式。它把数据库方案和无中心方案的优点合到了一起也算是分布式ID领域的集大成者。4.1 Leaf-segment号段模式批量取号与性能优化号段模式的核心思想非常朴素别每次生成ID都请求数据库而是一次性从数据库领一批号码在内存里慢慢分配。数据库里建一张表核心字段就是biz_tag业务标识和max_id当前已分配的最大ID。假设步长设置为1000流程是这样的应用启动按业务标识读到当前max_id。在内存里预加载[max_id1, max_id1000]这1000个ID同时把数据库里的max_id更新为max_id1000。业务请求ID时直接从内存里递增分配不碰数据库。内存号段用完了再去数据库领下一批。这个方案的妙处在于数据库从“每次生成都访问”降级为“周期性批量访问”压力下降了几个数量级。1000个号段一次性领了等用完再去领中间这1000次请求完全零IO。但问题也随之而来如果号段正好用尽而应用需要继续生成ID就要被迫等待数据库交互返回。高并发下这短暂间隙的延迟会被放大。Leaf给的解法是双Buffer机制。核心是维护两个号段一个当前正在用一个持续预加载下一批。当前号段的ID消耗到一定比例比如40%时异步线程就开始去后台把另一个号段的号码补满。使用者在“当前号段耗尽”和“下一批已有备用”之间永远无缝衔接几乎感知不到数据库交互的延迟。从实现上讲biz_tag是个好东西。不同的业务线可以拥有独立的ID空间互不干扰。比如订单系统一个tag、支付流水一个tag各自步长也能按流量分别调。它的短板也很明显依赖数据库。数据库就是那个全局协调点如果数据库挂了号段分配服务也就挂了。所以生产环境至少要给号段表做一主多从、高可用切换。4.2 Leaf-snowflake工程化后的雪花模式Leaf的第二种模式是对经典雪花算法的工程化升级。它在纯雪花算法的基础上主要解决了三个工程问题机器ID的自动发放与持久化Leaf通过协调服务下发workerId同时把workerId存到本地缓存。下次启动时优先读取本地文件里的workerId没有再向协调服务申请。这样既避免反复申请导致协调服务抖动又能快速恢复。时间回拨的主动规避启动时检查本地缓存里记录的上一次时间戳如果当前系统时间小于它说明发生了回拨直接启动失败并告警。运行期间如果发现回拨也会停止服务等待时间追上。运行状态的可观测性网关层会把最近生成ID的“最大时间差”、“累计生成量”等指标暴露出来方便监控。这一点在自研方案里经常被忽略但线上出事时有没有监控完全是两种体验。4.3 号段与雪花怎么选Leaf同时提供两种模式那到底选哪个我的经验里可以按这样一个逻辑来判断对ID趋势递增有严格要求且并发量很大的业务比如订单、支付流水、消息记录优先考虑号段模式。因为它在内存里连续分配ID是严格有序递增的对数据库索引友好度最高。希望无中心化、不依赖数据库、也不怕偶尔重度阻塞的系统优先考虑雪花模式。因为雪花算法不依赖外部存储只要机器时钟稳定任何节点都能独立生成ID适合对可用性要求极高的核心链路。不过现实业务里很多公司并不会硬选一种。一是因为Leaf本身就能同时支撑多种模式二是不同业务对ID的诉求真的不一样。合理做法是搭建一台ID服务网关对上游业务屏蔽底层模式由网关按业务配置决定走号段还是雪花。5. 三种方案横向对比与选型建议到了这一步三种方案各自的技术细节都清楚了最后要做的是把它们放在同一张桌子上去对比。5.1 一张表看清三者的本质差异对比项UUIDSnowflake雪花算法Leaf-segment号段模式全局唯一高概率保证绝对保证位段组合绝对保证数据库协调趋势递增v4随机无序v1部分有序严格趋势递增严格递增生成性能极快纯内存/随机极快纯位运算快速内存内分配极低DB交互存储开销36字符或16字节二进制8字节BIGINT8字节BIGINT外部依赖无仅依赖本机时钟依赖数据库基础设施要求无机器时钟尽量稳定数据库需高可用单机QPS很高理论约409.6万/秒取决于号段步长与双Buffer切换速度看这个表就会发现三者其实处于不同地带。UUID最省事但是代价最大雪花算法在性能和独立性之间平衡得最好号段模式在数据库可靠的前提下能提供最稳的递增语义。5.2 不同业务场景下的选型建议根据我实际经手的项目给出几个比较有代表性的建议可以直接参考新项目起步数据量不大团队人力紧张直接用雪花算法自研一个生成器甚至直接复用成熟开源实现把机器ID做好分配完全够用。系统已有Sharding-JDBC或MyCat这类分库分表中间件它们自带的分布式主键策略底层多数就是雪花算法变体没必要再额外造轮子用中间件能力即可。金融或电商核心链路对ID有序性要求极高且有能力维护数据库高可用号段模式更稳。尤其是订单、流水这类高频写入场景严格递增对冷热数据分离、归档分表都非常有利。日志系统、用户行为上报这类海量、低耦合、不关心顺序的数据UUID甚至比雪花更合适。省心、无状态、无依赖。对外API的ID对外可见不希望别人推算出业务量两种方案都不完美。建议在ID生成后加一层“混淆”比如倒序、异或加密、或转成62进制缩短同时保留内部有序性。5.3 实操过程中的几个提醒选型只是第一步真正把方案落地的时候有几个细节是经常被忽略的ID生成器的线程安全这不是小事。雪花算法和号段模式的ID分配都要求多线程并发访问时严格互斥。因为Bug导致两个线程拿到同一个ID数据落库时主键冲突会直接冒出来。务必用synchronized或内部锁保护好核心递增逻辑。核心系统要监控不管用什么方案都要把“生成失败次数”、“回拨次数”、“耗时分布”这类指标暴露出来。很多问题不是方案不行而是到了出事那天才发现连监控都没有。预发环境和线上环境的机器ID隔离各种环境共用一套雪花算法时机器ID重叠会导致生产数据里混入“理论上不会存在”的重复ID。建议通过配置中心按环境划分机器ID段位。6. 个人踩坑记录与最终的落地建议文章最后分享几个真实经历过的教训吧虽然不是那种特别高级的技术点但每条都是真金白银换来的。第一个教训依赖本机时钟的方案一定要处理回拨。我们曾经有一套心跳调度逻辑每次生成ID前要读本机时间。某次服务器时间被运维手动拨慢了半小时好在监控及时报警不然后果不堪设想。从那以后我在所有依赖时钟的方案里都强制加了“校验降级”逻辑。第二个教训机器ID的持久化不能省。刚开始觉得每次启动用IP生成机器ID就行后来发现有些容器平台的IP是动态变化的同一台Pod重启后IP变了机器ID就变了。从那里以后凡是长期运行的节点我都坚持把机器ID落盘保存。第三个教训别小看“业务故障恢复”对ID连续性的影响。号段模式的数据库如果发生了回滚max_id可能倒退。步长只增不减是业内默认的底线无论你中间出了什么岔子都不允许修改回旧值。牺牲一段不连续的ID换来的是一整套系统的安全。最后一个建议很实诚如果你们的团队连一个专门的基础设施团队都凑不齐别轻易自研分布式ID服务。优先级排序应该是先用成熟开源组件或中间件内置方案等业务真正复杂到需要“统一发号”了再基于雪花算法和号段原理搭建团队自己的方案。分布式ID这件事踩坑容易造轮子造得稳才是本事。