做了这么多年订单系统我越来越觉得一个看起来最不值钱的订单号往往最能看出团队对并发、容灾和基础组件的理解。分布式唯一订单编号生成器这个名字一听就很“中间件”但它本质上就做一件事在海量订单同时落库的时候给每笔订单一个不重复、不吵架、不背锅的编号。这篇文章不是把概念重新抄一遍而是把从需求拆解、方案对比、核心实现到线上坑位的完整过程摊开讲适合正在做订单、交易、支付系统的开发者也适合准备把ID生成器从单体里拆出去的设计师。1. 先搞清楚订单号到底在解决什么问题1.1 全局唯一只是及格线如果只是追求“不重复”其实方案多得很UUID 一梭子下去就能保证唯一。但订单号不是给自己看的它是整个交易链路里的通用凭证要进数据库、要写日志、要传到前端、要透传给第三方还要支撑对账、退款、客服查单。这些场景叠加在一起对订单号的要求就不只是唯一还有趋势递增、可解析、高性能、高可用。唯一是底线任何方案都不能越线。趋势递增影响数据库写入性能尤其在使用 InnoDB 这类聚簇索引的存储引擎时主键有序性直接决定插入操作会不会频繁触发页分裂。订单号如果毫无规律主键索引就像一本不断被打乱重编的字典写入放大、随机IO、缓冲池命中率下降都会跟着来。业务可读性和可解析性也很重要。传统做法是把时间戳、机器位、序列位揉进一个数字里订单号本身就能透露生成时刻、哪个节点生成、同一毫秒生成的第几笔。这不是为了炫技而是为了排查问题。线上订单积压时我经常直接从订单号里截取时间位段做粗筛不用先查流水表就能判断是某个时段集中出问题还是某台机器有问题。1.2 趋势递增与业务可读性的价值数据库索引和分库分表是两个最直接的受益方。比如订单表按月分表如果订单号头部带着时间信息路由逻辑可以直接截取字符串或做位运算不需要额外读一张映射表。相比随机字符串ID这种可路由的ID设计能省掉一次 Redis 或 DB 查询。趋势递增还有一个附加好处默认排序天然接近业务时间顺序。用户订单列表按订单号倒序展示时基本等价于“最近下的单排在前面”不用再单独维护 create_time 索引来扛查询压力。当然这不是说 create_time 可以删而是说订单号可以作为辅助排序维度让部分查询降级时也能稳住。我见过不少团队在设计阶段嫌弃订单号里塞时间戳太“土”非要用纯随机串。结果上生产后主键索引碎片率高得吓人insert 性能随着数据量增长快速下降。后来切换到携带有序信息的ID生成器同样规模的写入量数据库负载肉眼可见地降下来。这个教训说明业务可读性不是为了好看是为了让整条链路都受益。1.3 高性能与可用性约束订单号生成器看似是几行代码但它部署在交易关键路径上生成一次ID发生在写库之前。如果生成器响应慢订单创建接口直接变慢如果生成器挂了等于全站无法下单。这决定了它不能是那种“尽力而为”的组件必须有明确的性能边界和高可用设计。性能上单机至少要做到每秒百万级生成能力。如果接入层高峰期只有几万 QPS听起来单机不是瓶颈但订单号生成器的调用往往不止在主流程还有售后单、工单、优惠券核销等其他业务在复用。一旦把它作为统一发号组件流量会翻好几倍低估它很容易被打脸。可用性上主要看两点一是进程内状态不能因为异常导致ID重复二是机器ID/时钟这些外部因素漂移时系统能快速感知。真正的分布式ID生成器不是做完算法就结束后续的注册、自检、监控、降级才是线上稳定运行的关键。很多线上事故都发生在“生成算法没问题但部署环境出了岔子”的情况。2. 主流方案逐个过一遍2.1 UUID为什么看起来那么像反面教材UUID 有 128 位通常写成 36 字符的十六进制串。它生成简单、本地就能跑、不需要任何中心节点看起来非常美好。但一旦把它用作订单表主键问题就来了随机性太强导致索引页分裂频繁字符串存储空间大普通 bigint 占 8 字节UUID 字符串轻松上 36 字节日志和接口字段也跟着变长链路开销被放大。有人会提 UUID v7它在时间戳上做了有序化改造确实改善了索引问题但字符串长度和可读性问题还在。而且不同语言、不同数据库对 UUID v7 的支持程度参差不齐真要全链路统一处理反而增加复杂度。按我的经验除非是离线数据、边缘节点或者客户端本地生成的低频场景否则订单号不建议直接用 UUID。有一种变体是把 UUID 转成纯数字但要保留唯一性通常得截取足够长的二进制位最后得到的十进制数不比 Snowflake ID 短还丢了时间有序性。折腾一圈下来不如直接上一套专门为业务设计的 ID 方案。2.2 数据库自增和号段模式数据库自增 ID 是最朴素的做法。单库单表没问题但一旦分库分表要么设置不同步长要么引入中心化的发号表复杂度立刻上来。而且数据库自身在高并发下很快就成为瓶颈一个订单插入前先拿一把数据库锁去自增等于把写库压力前置放大。号段模式是自增ID的高性能改良版。核心思路是每次从中心数据库取一批号段比如一次取 1000 个应用内存里发完再去取下一批。这样数据库访问次数大幅减少性能比逐条自增好很多。实现上可以用一条 SQL 做原子更新update id_segment set current_max current_max step where biz_tag ?更新成功后新的号段就是区间(old_max, new_max]。号段模式也有坑一是应用重启会浪费已加载未发完的号段二是中心表一旦崩了所有依赖节点的号段用完后集体停摆。更关键的是号段模式产出的ID虽然整体递增但节点之间拿到的是连续区间分布式环境下容易出现“A节点正在生成B节点反而拿到更大号段”的情况严格的时间有序性并不好。它适合对顺序要求不极端的场景但不适合需要从ID里直接读出时间维度的订单系统。2.3 雪花算法分布式ID的集大成者雪花算法Snowflake解决了前面几个方案的大部分痛点。它用一个 64 位长整型做载体按位拆成符号位、时间戳、工作机器ID、序列号四段既保持了趋势递增又具备高性能和强唯一性。部署时每台机器有独立 workerId互不干扰理论上单机每毫秒能生成 4096 个 ID支撑百万级 QPS 没有压力。它最大的一个优点是 ID 里自带时间戳不用额外字段就能做时间维度的粗筛。另一个优点是纯数值型可以存 bigint传 JSON 时只要处理一下 JS 精度问题即可。市面上各种增强版雪花算法层出不穷但主体结构基本不变核心差异都集中在机器ID分配、时钟回拨处理和序列号溢出策略上。主流的几种方案对比如下方案唯一性趋势递增单机性能主要缺点适用场景UUID高否极高存储大、索引差离线、非主键数据库自增高是低单点、性能瓶颈单体低并发号段模式高基本是中引入中心依赖批量发号雪花算法高是极高依赖时钟、机器ID分布式高并发结论很清楚订单号生成器用雪花算法做骨架再针对业务做定制改造是最稳妥的路径。接下来我贴一版我在项目里实际用过的核心实现代码不炫技重点是每一步都能解释清楚。3. 自己动手订单号生成器核心实现3.1 订单号的数据结构设计我用的标准位分布是 1 位符号 41 位毫秒时间戳 10 位机器ID 12 位序列号整体是一个 64 位 long。符号位始终为 0保证生成的数是正整数。41 位时间戳从自定义起始时间开始计算可以支撑大约 69 年。我不建议从 Unix 元年 1970 年开始算因为那样很快会逼近 41 位能表达的时间上限从项目上线时间附近开始算位数利用率更高。10 位机器ID最多支持 1024 个节点。对绝大多数订单系统来说这个数量足够。如果公司规模大到超过这个节点数可以压缩时间戳位数或者扩展机器ID位数但一般情况下完全没有必要提前扩位数。12 位序列号表示每毫秒 4096 个序号单机理论 QPS 约为 409.6 万已经远超正常业务流量。最终生成的 long 转成十进制后一般不超过 19 位。不同系统的订单号位数要求不一样有的要求 20 位那可以在拼接成字符串时在最前面补一个业务类型前缀比如固定两位再左补零到 18 位。注意一点一旦定了位数规则就不要随便改订单号会进报表、进对账单、进第三方系统规则一变全链路都要跟着动。3.2 核心代码与生成流程下面是核心生成器的简化版代码。我抽掉了公司内部配置加载的细节保留最关键的状态流转。这一段看懂后后续进阶优化都是在它上面打补丁。public class OrderIdGenerator { /** 起始时间戳取项目上线时间2024-01-01 00:00:00 */ private static final long START_EPOCH 1704067200000L; /** 机器ID位数 */ private static final long WORKER_ID_BITS 10L; /** 序列号位数 */ private static final long SEQUENCE_BITS 12L; /** 最大机器ID 1023 */ private static final long MAX_WORKER_ID ~(-1L WORKER_ID_BITS); /** 最大序列号 4095 */ private static final long MAX_SEQUENCE ~(-1L SEQUENCE_BITS); /** 机器ID左移位数 */ private static final long WORKER_ID_SHIFT SEQUENCE_BITS; /** 时间戳左移位数 */ private static final long TIMESTAMP_SHIFT WORKER_ID_BITS SEQUENCE_BITS; private final long workerId; private long sequence 0L; private long lastTimestamp -1L; public OrderIdGenerator(long workerId) { if (workerId 0 || workerId MAX_WORKER_ID) { throw new IllegalArgumentException(workerId out of range); } this.workerId workerId; } public synchronized long nextId() { long timestamp System.currentTimeMillis(); // 时钟回拨保护 if (timestamp lastTimestamp) { long offset lastTimestamp - timestamp; if (offset 5) { // 小幅度回拨等 2 倍差值等到系统时间追上来 try { Thread.sleep(offset 1); } catch (InterruptedException e) { Thread.currentThread().interrupt(); throw new IllegalStateException(interrupted while waiting clock, e); } timestamp System.currentTimeMillis(); if (timestamp lastTimestamp) { throw new IllegalStateException(clock moved backwards, refuse to generate id); } } else { throw new IllegalStateException(clock moved backwards, refuse to generate id); } } // 同一毫秒内序列号递增 if (timestamp lastTimestamp) { sequence (sequence 1) MAX_SEQUENCE; if (sequence 0) { // 当前毫秒序列号耗尽等待下一毫秒 timestamp tilNextMillis(lastTimestamp); } } else { // 新的一毫秒序列号从 0 开始 sequence 0L; } lastTimestamp timestamp; return ((timestamp - START_EPOCH) TIMESTAMP_SHIFT) | (workerId WORKER_ID_SHIFT) | sequence; } private long tilNextMillis(long lastTimestamp) { long timestamp System.currentTimeMillis(); while (timestamp lastTimestamp) { timestamp System.currentTimeMillis(); } return timestamp; } }这段代码的核心操作可以拆成三步。第一步取当前毫秒时间戳如果发现它比上次生成ID时还要小说明时钟回拨了这是分布式ID最容易翻车的地方。第二步根据是否处于同一毫秒决定序列号是递增还是归零所有分支都保证同一毫秒内不重号。第三步把三段二进制位拼接到一起用左移和或运算组合成一个 long位运算效率远高于字符串拼接。注意代码里用了synchronized让同一个 JVM 内的多个线程并发调用时全部排队进入临界区。很多人看到锁就担心性能但这里临界区只有几次位运算和状态判断非常短。实际上 JVM 对无竞争 synchronized 做了大量优化单机百万 QPS 完全顶得住。如果仍然觉得锁有压力可以换成AtomicLong做 CAS 自旋但代码可读性会下降我建议先测一下再决定要不要优化。3.3 时钟回拨与序列号溢出处理时钟回拨是雪花算法最经典的敌人。NTP 校时、虚拟机时钟漂移、手动改服务器时间都可能导致System.currentTimeMillis()比上次出现时变小。如果不做处理新的ID和已生成的ID撞车的概率非常高。我常用的策略是分级处理。回拨幅度很小比如 5 毫秒以内就短暂 sleep 等待系统时间追上来然后把这次请求当作“时钟恢复期”继续生成。回拨幅度较大说明环境异常这时候不能假装没事继续发号宁可让上游感知到异常也不要带着隐患硬顶。生产环境里我加过监控一旦触发回拨拒绝立刻报警绝大多数情况下是运维手动改时间或者 NTP 配置出错。还有个容易忽略的细节序列号溢出。12 位序列号最多 4096 个同一毫秒第 4097 个请求进来时序列号重新归零此时不能再生成必须自旋等到下一毫秒。这段逻辑用while循环自旋开销很小但要注意不能空转太久否则线程会白白占着 CPU。高并发场景下如果 QPS 真的超过单机 409.6 万说明节点数不够扩容机器比优化代码更实际。序列号的起点也可以微调。比如要求订单号不能从 0 开始怕被外部猜到当天生成量那就在换毫秒时随机初始化序列号。但这么做会损失部分容量也让时序特征不再清晰我认为没有必要订单号不是安全凭证真正需要防猜的是签名和令牌。4. 部署落地机器ID分配与性能压测4.1 选择内嵌还是独立服务订单号生成器有两种落地姿势内嵌 SDK 和独立发号服务。内嵌模式把生成器打成依赖包放到订单应用里应用进程启动时加载 workerId直接本地生成 ID。这种方式延迟最低不增加额外网络调用可用性上限高因为即使注册中心或数据库宕机只要 workerId 已经加载节点也可以继续生成 ID。独立服务模式也叫发号中心所有业务方通过网络请求获取 ID。统一入口方便管控、方便做配额、也方便动态调整机器ID但代价是每次生成都多一次 RPC。以订单主流程的 QPS 来看独立发号服务需要非常高的吞吐设计扛不住就会拖累全局。如果公司业务线多、ID规范复杂我建议独立服务如果只是订单系统内部用内嵌 SDK 更省心。我们当时选择的是内嵌模式加注册表管理。理由很简单订单主链路已经够重不能再加一个中心节点。只要把机器ID分配、启动自检、监控上报做好内嵌模式在稳定性上并不输独立服务省掉的 RPC 时间在高并发下也很值钱。4.2 机器ID的分配与回收机制机器ID是分布式模式下唯一性的前提它的分配必须保证任何时刻都不能重复。最简单可靠的逻辑是启动时从 worker 注册表里取ID先查当前机器 IP 是否已登记有则复用原ID没有则插入一条记录拿到自增ID。自增ID的单调性天然保证不重复只要应用进程不主动释放ID其他机器就不会再次拿到同一个值。具体实现可以建一张表核心字段就三个应用标识、IP、机器名。启动流程变成先查应用标识和 IP 对应的记录查到就返回已有 ID查不到就插入利用数据库自增返回新 ID。这里要防住一个并发陷阱两个实例同时启动且都没有记录时必须靠数据库唯一索引兜底让其中一个插入失败后重新查询。回收机制不需要做得太频繁。订单系统很少大规模扩缩容大部分时候实例是长活的机器ID复用周期很长。真要支持弹性伸缩可以加定期心跳续约超时未续约的ID标记为可回收。我之前在注册表里加过最后心跳时间每 30 秒更新一次超过 3 分钟没有心跳就告警但不会立刻回收避免只是网络抖动导致两个实例拿到同一个ID。4.3 压测指标与目标先算理论上限单机每毫秒 4096 个 ID一秒就是 409.6 万。10 个节点加起来将近 4000 万正常业务根本摸不到这个天花板。真实压测时瓶颈往往不在生成器本身而在测试框架、日志输出、统计聚合这些旁路。我用一个简单脚本验证过基本性能8 个线程并发调用 100 万次只统计生成耗时不落库、不打日志跑下来大概在几百毫秒量级。然后我会跑一个“三连查”验证唯一性把所有生成的ID写入内存集合判断是否有重复再把ID按时间戳位段排序确认整体呈趋势递增最后用工具解析ID里的 workerId确认所有节点都有产出。这三个检查都通过才敢把新版本推到预发。压测分数不能只看均值要关注 p99。订单号生成虽然临界区短但如果上游应用线程堆叠、GC 发生延迟照样会被放大。我习惯把 p99 压到 5 毫秒以内作为安全水位超过这个值就检查调用方是不是在锁内做了别的 IO 操作。5. 常见问题排查实录5.1 线上重复ID排查重复ID是这类组件的“核事故”一旦发生订单表主键冲突会把写入流程打断。我排查过几次最典型的原因不是算法问题而是机器ID分配重叠。比如环境重建后新老实例同时注册成功或者注册表被清理后老实例还在线上跑两个进程带着同一个 workerId 在发号。排查第一步不是翻代码而是把重复ID拿到手里做位解析。确认它的时间戳位段、机器ID位段、序列号位段分别是什么。如果两个重复ID的机器ID位段相同基本可以断定是 workerId 冲突如果机器ID不同但ID整体一样那就要怀疑是不是数据拷贝导致旧数据冲突。第二步查时间。对比重复ID对应的时间戳和服务器 NTP 日志看是否发生过较大幅度时间跳变。时钟回拨的典型特征是短时间内出现小于上次时间戳的请求并且在监控上表现为拒绝计数上升。把生成器自身的指标报表拉出来一眼就能定位。5.2 订单号在传输中被“截胡”的坑这个坑特别容易踩但它不是生成器的问题而是调用方的问题。Snowflake ID 是一个 64 位 long超过 JavaScript 的Number.MAX_SAFE_INTEGER也就是 9007199254740991。前端拿到 JSON 里的数字后一旦超过这个值精度就会丢失最后一位可能变成 0 或出现偏差。下过单的用户看到订单号不对客服一查又对不上非常难受。解决方式不是不用 Snowflake而是把订单号以字符串形式传给前端。Java 体系里可以用 Jackson 的ToStringSerializer对 Long/Long 类型做全局序列化或者干脆在 DTO 里把 ID 字段声明为 String生成后调用Long.toString()。这个改动要覆盖 Web 层、日志、消息、对外接口等所有出口漏掉一个都会引发追踪困难。数据库存储也要注意订单号用bigint unsigned或者bigint都可以但如果前端传回来的是字符串中间件类型转换时一定要兼容。我在项目里统一规定订单号在服务间传递一律用 string只有落到数据库索引时才允许转成数值型。5.3 流量突刺时的序列号竞争大促流量是订单号的试金石。平时每秒几百个订单突然瞬间冲到每秒几十万虽然离 409.6 万的天花板还很远但应用线程数增加后synchronized临界区的竞争会明显加剧表现为生成ID的 p99 上涨。此时要分清是临界区本身慢还是线程调度被打乱。多数情况下稍微治理一下调用方的线程池就够了。真正靠近阈值时可以给生成器增加前置缓冲用一个环形数组把未来几毫秒的序列空间预分配出来请求进来直接取一个已生成的ID。但这套方案复杂且容易破坏趋势递增我很少建议直接上不如多部署一台实例分摊压力更实在。如果确认单机 QPS 极高可以把部分非交易场景的ID生成切到独立的 workerId 或独立的序列区间比如退款单、工单不再和订单共用同一个序列序列空间。这个隔离策略比在算法上死磕性能更有效也让故障面更小。6. 我踩过的一些坑最后一个主题不写总结了分享几个实际踩坑记录。第一次上线时我只测了唯一性没有测趋势递增结果某台服务器时钟落后了一百多毫秒导致它生成的订单号时间位段比另一台机器旧用户看到的订单排序忽前忽后。后来我把机器启动时的时钟校验加了进去偏差超过阈值直接拒绝启动宁可多等几秒也不带病上线。序列号初始值的设置也有讲究。早期版本为了显得“随机”每次进入新毫秒都把序列号设置成随机数结果容量直接从 4096 降到可能只有几十反正累计生成的ID数量少了一大截。后来看到压测报告才发现这个问题改成从 0 开始后峰值吞吐恢复正常。NTP 的配置千万别忽略。我遇到过一台虚拟机不停小幅度回拨每次就一两毫秒不仔细观察监控根本看不出来。后来在生成器里加了两个核心指标lastTimestamp - currentTimestamp的最大回拨值以及序列号使用率。这两个指标配合起来比事后看日志直观得多。序列号使用率持续超过 80% 时就说明当前节点容量紧张该扩容了。还有一个小技巧单元测试里一定模拟时钟回拨。把System.currentTimeMillis()的调用封装成一个可替换的 Clock 对象测试时直接让时间倒流验证生成器是快速失败还是等待追平。这个测试用例看着不起眼但能挡住后续几乎所有因为修改时间逻辑而引入的回归。 
长河君 · 2026/10/21 22:02:57 · 阅读 1.2k 分布式订单号生成器：从雪花算法到高并发实践
做了这么多年订单系统我越来越觉得一个看起来最不值钱的订单号往往最能看出团队对并发、容灾和基础组件的理解。分布式唯一订单编号生成器这个名字一听就很“中间件”但它本质上就做一件事在海量订单同时落库的时候给每笔订单一个不重复、不吵架、不背锅的编号。这篇文章不是把概念重新抄一遍而是把从需求拆解、方案对比、核心实现到线上坑位的完整过程摊开讲适合正在做订单、交易、支付系统的开发者也适合准备把ID生成器从单体里拆出去的设计师。1. 先搞清楚订单号到底在解决什么问题1.1 全局唯一只是及格线如果只是追求“不重复”其实方案多得很UUID 一梭子下去就能保证唯一。但订单号不是给自己看的它是整个交易链路里的通用凭证要进数据库、要写日志、要传到前端、要透传给第三方还要支撑对账、退款、客服查单。这些场景叠加在一起对订单号的要求就不只是唯一还有趋势递增、可解析、高性能、高可用。唯一是底线任何方案都不能越线。趋势递增影响数据库写入性能尤其在使用 InnoDB 这类聚簇索引的存储引擎时主键有序性直接决定插入操作会不会频繁触发页分裂。订单号如果毫无规律主键索引就像一本不断被打乱重编的字典写入放大、随机IO、缓冲池命中率下降都会跟着来。业务可读性和可解析性也很重要。传统做法是把时间戳、机器位、序列位揉进一个数字里订单号本身就能透露生成时刻、哪个节点生成、同一毫秒生成的第几笔。这不是为了炫技而是为了排查问题。线上订单积压时我经常直接从订单号里截取时间位段做粗筛不用先查流水表就能判断是某个时段集中出问题还是某台机器有问题。1.2 趋势递增与业务可读性的价值数据库索引和分库分表是两个最直接的受益方。比如订单表按月分表如果订单号头部带着时间信息路由逻辑可以直接截取字符串或做位运算不需要额外读一张映射表。相比随机字符串ID这种可路由的ID设计能省掉一次 Redis 或 DB 查询。趋势递增还有一个附加好处默认排序天然接近业务时间顺序。用户订单列表按订单号倒序展示时基本等价于“最近下的单排在前面”不用再单独维护 create_time 索引来扛查询压力。当然这不是说 create_time 可以删而是说订单号可以作为辅助排序维度让部分查询降级时也能稳住。我见过不少团队在设计阶段嫌弃订单号里塞时间戳太“土”非要用纯随机串。结果上生产后主键索引碎片率高得吓人insert 性能随着数据量增长快速下降。后来切换到携带有序信息的ID生成器同样规模的写入量数据库负载肉眼可见地降下来。这个教训说明业务可读性不是为了好看是为了让整条链路都受益。1.3 高性能与可用性约束订单号生成器看似是几行代码但它部署在交易关键路径上生成一次ID发生在写库之前。如果生成器响应慢订单创建接口直接变慢如果生成器挂了等于全站无法下单。这决定了它不能是那种“尽力而为”的组件必须有明确的性能边界和高可用设计。性能上单机至少要做到每秒百万级生成能力。如果接入层高峰期只有几万 QPS听起来单机不是瓶颈但订单号生成器的调用往往不止在主流程还有售后单、工单、优惠券核销等其他业务在复用。一旦把它作为统一发号组件流量会翻好几倍低估它很容易被打脸。可用性上主要看两点一是进程内状态不能因为异常导致ID重复二是机器ID/时钟这些外部因素漂移时系统能快速感知。真正的分布式ID生成器不是做完算法就结束后续的注册、自检、监控、降级才是线上稳定运行的关键。很多线上事故都发生在“生成算法没问题但部署环境出了岔子”的情况。2. 主流方案逐个过一遍2.1 UUID为什么看起来那么像反面教材UUID 有 128 位通常写成 36 字符的十六进制串。它生成简单、本地就能跑、不需要任何中心节点看起来非常美好。但一旦把它用作订单表主键问题就来了随机性太强导致索引页分裂频繁字符串存储空间大普通 bigint 占 8 字节UUID 字符串轻松上 36 字节日志和接口字段也跟着变长链路开销被放大。有人会提 UUID v7它在时间戳上做了有序化改造确实改善了索引问题但字符串长度和可读性问题还在。而且不同语言、不同数据库对 UUID v7 的支持程度参差不齐真要全链路统一处理反而增加复杂度。按我的经验除非是离线数据、边缘节点或者客户端本地生成的低频场景否则订单号不建议直接用 UUID。有一种变体是把 UUID 转成纯数字但要保留唯一性通常得截取足够长的二进制位最后得到的十进制数不比 Snowflake ID 短还丢了时间有序性。折腾一圈下来不如直接上一套专门为业务设计的 ID 方案。2.2 数据库自增和号段模式数据库自增 ID 是最朴素的做法。单库单表没问题但一旦分库分表要么设置不同步长要么引入中心化的发号表复杂度立刻上来。而且数据库自身在高并发下很快就成为瓶颈一个订单插入前先拿一把数据库锁去自增等于把写库压力前置放大。号段模式是自增ID的高性能改良版。核心思路是每次从中心数据库取一批号段比如一次取 1000 个应用内存里发完再去取下一批。这样数据库访问次数大幅减少性能比逐条自增好很多。实现上可以用一条 SQL 做原子更新update id_segment set current_max current_max step where biz_tag ?更新成功后新的号段就是区间(old_max, new_max]。号段模式也有坑一是应用重启会浪费已加载未发完的号段二是中心表一旦崩了所有依赖节点的号段用完后集体停摆。更关键的是号段模式产出的ID虽然整体递增但节点之间拿到的是连续区间分布式环境下容易出现“A节点正在生成B节点反而拿到更大号段”的情况严格的时间有序性并不好。它适合对顺序要求不极端的场景但不适合需要从ID里直接读出时间维度的订单系统。2.3 雪花算法分布式ID的集大成者雪花算法Snowflake解决了前面几个方案的大部分痛点。它用一个 64 位长整型做载体按位拆成符号位、时间戳、工作机器ID、序列号四段既保持了趋势递增又具备高性能和强唯一性。部署时每台机器有独立 workerId互不干扰理论上单机每毫秒能生成 4096 个 ID支撑百万级 QPS 没有压力。它最大的一个优点是 ID 里自带时间戳不用额外字段就能做时间维度的粗筛。另一个优点是纯数值型可以存 bigint传 JSON 时只要处理一下 JS 精度问题即可。市面上各种增强版雪花算法层出不穷但主体结构基本不变核心差异都集中在机器ID分配、时钟回拨处理和序列号溢出策略上。主流的几种方案对比如下方案唯一性趋势递增单机性能主要缺点适用场景UUID高否极高存储大、索引差离线、非主键数据库自增高是低单点、性能瓶颈单体低并发号段模式高基本是中引入中心依赖批量发号雪花算法高是极高依赖时钟、机器ID分布式高并发结论很清楚订单号生成器用雪花算法做骨架再针对业务做定制改造是最稳妥的路径。接下来我贴一版我在项目里实际用过的核心实现代码不炫技重点是每一步都能解释清楚。3. 自己动手订单号生成器核心实现3.1 订单号的数据结构设计我用的标准位分布是 1 位符号 41 位毫秒时间戳 10 位机器ID 12 位序列号整体是一个 64 位 long。符号位始终为 0保证生成的数是正整数。41 位时间戳从自定义起始时间开始计算可以支撑大约 69 年。我不建议从 Unix 元年 1970 年开始算因为那样很快会逼近 41 位能表达的时间上限从项目上线时间附近开始算位数利用率更高。10 位机器ID最多支持 1024 个节点。对绝大多数订单系统来说这个数量足够。如果公司规模大到超过这个节点数可以压缩时间戳位数或者扩展机器ID位数但一般情况下完全没有必要提前扩位数。12 位序列号表示每毫秒 4096 个序号单机理论 QPS 约为 409.6 万已经远超正常业务流量。最终生成的 long 转成十进制后一般不超过 19 位。不同系统的订单号位数要求不一样有的要求 20 位那可以在拼接成字符串时在最前面补一个业务类型前缀比如固定两位再左补零到 18 位。注意一点一旦定了位数规则就不要随便改订单号会进报表、进对账单、进第三方系统规则一变全链路都要跟着动。3.2 核心代码与生成流程下面是核心生成器的简化版代码。我抽掉了公司内部配置加载的细节保留最关键的状态流转。这一段看懂后后续进阶优化都是在它上面打补丁。public class OrderIdGenerator { /** 起始时间戳取项目上线时间2024-01-01 00:00:00 */ private static final long START_EPOCH 1704067200000L; /** 机器ID位数 */ private static final long WORKER_ID_BITS 10L; /** 序列号位数 */ private static final long SEQUENCE_BITS 12L; /** 最大机器ID 1023 */ private static final long MAX_WORKER_ID ~(-1L WORKER_ID_BITS); /** 最大序列号 4095 */ private static final long MAX_SEQUENCE ~(-1L SEQUENCE_BITS); /** 机器ID左移位数 */ private static final long WORKER_ID_SHIFT SEQUENCE_BITS; /** 时间戳左移位数 */ private static final long TIMESTAMP_SHIFT WORKER_ID_BITS SEQUENCE_BITS; private final long workerId; private long sequence 0L; private long lastTimestamp -1L; public OrderIdGenerator(long workerId) { if (workerId 0 || workerId MAX_WORKER_ID) { throw new IllegalArgumentException(workerId out of range); } this.workerId workerId; } public synchronized long nextId() { long timestamp System.currentTimeMillis(); // 时钟回拨保护 if (timestamp lastTimestamp) { long offset lastTimestamp - timestamp; if (offset 5) { // 小幅度回拨等 2 倍差值等到系统时间追上来 try { Thread.sleep(offset 1); } catch (InterruptedException e) { Thread.currentThread().interrupt(); throw new IllegalStateException(interrupted while waiting clock, e); } timestamp System.currentTimeMillis(); if (timestamp lastTimestamp) { throw new IllegalStateException(clock moved backwards, refuse to generate id); } } else { throw new IllegalStateException(clock moved backwards, refuse to generate id); } } // 同一毫秒内序列号递增 if (timestamp lastTimestamp) { sequence (sequence 1) MAX_SEQUENCE; if (sequence 0) { // 当前毫秒序列号耗尽等待下一毫秒 timestamp tilNextMillis(lastTimestamp); } } else { // 新的一毫秒序列号从 0 开始 sequence 0L; } lastTimestamp timestamp; return ((timestamp - START_EPOCH) TIMESTAMP_SHIFT) | (workerId WORKER_ID_SHIFT) | sequence; } private long tilNextMillis(long lastTimestamp) { long timestamp System.currentTimeMillis(); while (timestamp lastTimestamp) { timestamp System.currentTimeMillis(); } return timestamp; } }这段代码的核心操作可以拆成三步。第一步取当前毫秒时间戳如果发现它比上次生成ID时还要小说明时钟回拨了这是分布式ID最容易翻车的地方。第二步根据是否处于同一毫秒决定序列号是递增还是归零所有分支都保证同一毫秒内不重号。第三步把三段二进制位拼接到一起用左移和或运算组合成一个 long位运算效率远高于字符串拼接。注意代码里用了synchronized让同一个 JVM 内的多个线程并发调用时全部排队进入临界区。很多人看到锁就担心性能但这里临界区只有几次位运算和状态判断非常短。实际上 JVM 对无竞争 synchronized 做了大量优化单机百万 QPS 完全顶得住。如果仍然觉得锁有压力可以换成AtomicLong做 CAS 自旋但代码可读性会下降我建议先测一下再决定要不要优化。3.3 时钟回拨与序列号溢出处理时钟回拨是雪花算法最经典的敌人。NTP 校时、虚拟机时钟漂移、手动改服务器时间都可能导致System.currentTimeMillis()比上次出现时变小。如果不做处理新的ID和已生成的ID撞车的概率非常高。我常用的策略是分级处理。回拨幅度很小比如 5 毫秒以内就短暂 sleep 等待系统时间追上来然后把这次请求当作“时钟恢复期”继续生成。回拨幅度较大说明环境异常这时候不能假装没事继续发号宁可让上游感知到异常也不要带着隐患硬顶。生产环境里我加过监控一旦触发回拨拒绝立刻报警绝大多数情况下是运维手动改时间或者 NTP 配置出错。还有个容易忽略的细节序列号溢出。12 位序列号最多 4096 个同一毫秒第 4097 个请求进来时序列号重新归零此时不能再生成必须自旋等到下一毫秒。这段逻辑用while循环自旋开销很小但要注意不能空转太久否则线程会白白占着 CPU。高并发场景下如果 QPS 真的超过单机 409.6 万说明节点数不够扩容机器比优化代码更实际。序列号的起点也可以微调。比如要求订单号不能从 0 开始怕被外部猜到当天生成量那就在换毫秒时随机初始化序列号。但这么做会损失部分容量也让时序特征不再清晰我认为没有必要订单号不是安全凭证真正需要防猜的是签名和令牌。4. 部署落地机器ID分配与性能压测4.1 选择内嵌还是独立服务订单号生成器有两种落地姿势内嵌 SDK 和独立发号服务。内嵌模式把生成器打成依赖包放到订单应用里应用进程启动时加载 workerId直接本地生成 ID。这种方式延迟最低不增加额外网络调用可用性上限高因为即使注册中心或数据库宕机只要 workerId 已经加载节点也可以继续生成 ID。独立服务模式也叫发号中心所有业务方通过网络请求获取 ID。统一入口方便管控、方便做配额、也方便动态调整机器ID但代价是每次生成都多一次 RPC。以订单主流程的 QPS 来看独立发号服务需要非常高的吞吐设计扛不住就会拖累全局。如果公司业务线多、ID规范复杂我建议独立服务如果只是订单系统内部用内嵌 SDK 更省心。我们当时选择的是内嵌模式加注册表管理。理由很简单订单主链路已经够重不能再加一个中心节点。只要把机器ID分配、启动自检、监控上报做好内嵌模式在稳定性上并不输独立服务省掉的 RPC 时间在高并发下也很值钱。4.2 机器ID的分配与回收机制机器ID是分布式模式下唯一性的前提它的分配必须保证任何时刻都不能重复。最简单可靠的逻辑是启动时从 worker 注册表里取ID先查当前机器 IP 是否已登记有则复用原ID没有则插入一条记录拿到自增ID。自增ID的单调性天然保证不重复只要应用进程不主动释放ID其他机器就不会再次拿到同一个值。具体实现可以建一张表核心字段就三个应用标识、IP、机器名。启动流程变成先查应用标识和 IP 对应的记录查到就返回已有 ID查不到就插入利用数据库自增返回新 ID。这里要防住一个并发陷阱两个实例同时启动且都没有记录时必须靠数据库唯一索引兜底让其中一个插入失败后重新查询。回收机制不需要做得太频繁。订单系统很少大规模扩缩容大部分时候实例是长活的机器ID复用周期很长。真要支持弹性伸缩可以加定期心跳续约超时未续约的ID标记为可回收。我之前在注册表里加过最后心跳时间每 30 秒更新一次超过 3 分钟没有心跳就告警但不会立刻回收避免只是网络抖动导致两个实例拿到同一个ID。4.3 压测指标与目标先算理论上限单机每毫秒 4096 个 ID一秒就是 409.6 万。10 个节点加起来将近 4000 万正常业务根本摸不到这个天花板。真实压测时瓶颈往往不在生成器本身而在测试框架、日志输出、统计聚合这些旁路。我用一个简单脚本验证过基本性能8 个线程并发调用 100 万次只统计生成耗时不落库、不打日志跑下来大概在几百毫秒量级。然后我会跑一个“三连查”验证唯一性把所有生成的ID写入内存集合判断是否有重复再把ID按时间戳位段排序确认整体呈趋势递增最后用工具解析ID里的 workerId确认所有节点都有产出。这三个检查都通过才敢把新版本推到预发。压测分数不能只看均值要关注 p99。订单号生成虽然临界区短但如果上游应用线程堆叠、GC 发生延迟照样会被放大。我习惯把 p99 压到 5 毫秒以内作为安全水位超过这个值就检查调用方是不是在锁内做了别的 IO 操作。5. 常见问题排查实录5.1 线上重复ID排查重复ID是这类组件的“核事故”一旦发生订单表主键冲突会把写入流程打断。我排查过几次最典型的原因不是算法问题而是机器ID分配重叠。比如环境重建后新老实例同时注册成功或者注册表被清理后老实例还在线上跑两个进程带着同一个 workerId 在发号。排查第一步不是翻代码而是把重复ID拿到手里做位解析。确认它的时间戳位段、机器ID位段、序列号位段分别是什么。如果两个重复ID的机器ID位段相同基本可以断定是 workerId 冲突如果机器ID不同但ID整体一样那就要怀疑是不是数据拷贝导致旧数据冲突。第二步查时间。对比重复ID对应的时间戳和服务器 NTP 日志看是否发生过较大幅度时间跳变。时钟回拨的典型特征是短时间内出现小于上次时间戳的请求并且在监控上表现为拒绝计数上升。把生成器自身的指标报表拉出来一眼就能定位。5.2 订单号在传输中被“截胡”的坑这个坑特别容易踩但它不是生成器的问题而是调用方的问题。Snowflake ID 是一个 64 位 long超过 JavaScript 的Number.MAX_SAFE_INTEGER也就是 9007199254740991。前端拿到 JSON 里的数字后一旦超过这个值精度就会丢失最后一位可能变成 0 或出现偏差。下过单的用户看到订单号不对客服一查又对不上非常难受。解决方式不是不用 Snowflake而是把订单号以字符串形式传给前端。Java 体系里可以用 Jackson 的ToStringSerializer对 Long/Long 类型做全局序列化或者干脆在 DTO 里把 ID 字段声明为 String生成后调用Long.toString()。这个改动要覆盖 Web 层、日志、消息、对外接口等所有出口漏掉一个都会引发追踪困难。数据库存储也要注意订单号用bigint unsigned或者bigint都可以但如果前端传回来的是字符串中间件类型转换时一定要兼容。我在项目里统一规定订单号在服务间传递一律用 string只有落到数据库索引时才允许转成数值型。5.3 流量突刺时的序列号竞争大促流量是订单号的试金石。平时每秒几百个订单突然瞬间冲到每秒几十万虽然离 409.6 万的天花板还很远但应用线程数增加后synchronized临界区的竞争会明显加剧表现为生成ID的 p99 上涨。此时要分清是临界区本身慢还是线程调度被打乱。多数情况下稍微治理一下调用方的线程池就够了。真正靠近阈值时可以给生成器增加前置缓冲用一个环形数组把未来几毫秒的序列空间预分配出来请求进来直接取一个已生成的ID。但这套方案复杂且容易破坏趋势递增我很少建议直接上不如多部署一台实例分摊压力更实在。如果确认单机 QPS 极高可以把部分非交易场景的ID生成切到独立的 workerId 或独立的序列区间比如退款单、工单不再和订单共用同一个序列序列空间。这个隔离策略比在算法上死磕性能更有效也让故障面更小。6. 我踩过的一些坑最后一个主题不写总结了分享几个实际踩坑记录。第一次上线时我只测了唯一性没有测趋势递增结果某台服务器时钟落后了一百多毫秒导致它生成的订单号时间位段比另一台机器旧用户看到的订单排序忽前忽后。后来我把机器启动时的时钟校验加了进去偏差超过阈值直接拒绝启动宁可多等几秒也不带病上线。序列号初始值的设置也有讲究。早期版本为了显得“随机”每次进入新毫秒都把序列号设置成随机数结果容量直接从 4096 降到可能只有几十反正累计生成的ID数量少了一大截。后来看到压测报告才发现这个问题改成从 0 开始后峰值吞吐恢复正常。NTP 的配置千万别忽略。我遇到过一台虚拟机不停小幅度回拨每次就一两毫秒不仔细观察监控根本看不出来。后来在生成器里加了两个核心指标lastTimestamp - currentTimestamp的最大回拨值以及序列号使用率。这两个指标配合起来比事后看日志直观得多。序列号使用率持续超过 80% 时就说明当前节点容量紧张该扩容了。还有一个小技巧单元测试里一定模拟时钟回拨。把System.currentTimeMillis()的调用封装成一个可替换的 Clock 对象测试时直接让时间倒流验证生成器是快速失败还是等待追平。这个测试用例看着不起眼但能挡住后续几乎所有因为修改时间逻辑而引入的回归。