接手一个订单系统的改造时我真正意识到“雪花id生成器”不是一个可以随便从网上抄一段代码就完事的小工具。那套系统的订单表一直用数据库自增主键拆了分库分表之后自增ID在多个库之间重复显然行不通。换成UUID之后问题更直观32位乱序字符串落到B树索引里页分裂严重插入性能下降得厉害而且下游做订单号展示时根本没眼看。那段时间我每天想的就是——有没有一种ID既全局唯一又能大致按时间递增最好还能直接塞进long类型里让数据库和缓存都舒服。后来我决定在自己的系统里全面启用雪花ID生成器。从原理、手写实现、生产级坑位、性能优化到选型红线这篇文章把这一路沉淀下来的东西完整写一遍。无论你只是听说过雪花ID、正准备手写一个还是在纠结现有实现为什么会有重复ID都应该能从里面找到自己想看的。1. 开局先看位布局411012 到底怎么塞进一个 long1.1 用二进制视角重看“唯一且有序”雪花ID的核心是一个64位的long。long在Java里占8字节最高位是符号位通常保持为0这样才能保证ID是正数。剩下63位被拆成三段1位符号位固定为041位毫秒时间戳记录当前时间与某个自定义起始时间的差值10位工作机器ID用来区分不同的服务实例12位序列号表示同一毫秒内生成的第几个ID。也就是说一个标准雪花ID的二进制从高到低是这样的0 | 时间戳41bit | 机器ID10bit | 序列号12bit我用一个具体例子帮你建立直觉假设时间戳差值为1机器ID为2序列号为3那么拼出来的ID等于(1 22) | (2 12) | 3算一算等于4198403。你不需要背这个数只需要理解时间戳是ID里权重最大的高位所以ID总体会随时间的推进而单调递增机器ID保证了多节点之间不会冲突序列号则解决同一毫秒内多并发请求的区分问题。1.2 41位时间戳到底够用多少年41位二进制最大能表示2^41 - 1也就是2199023255551毫秒。换算一下2199023255551 / 1000 / 60 / 60 / 24 / 365 ≈ 69.7年所以如果你把起始时间epoch设置在2024年这套算法大约可以无符号地跑到2094年。这个年限对绝大多数业务系统都绰绰有余。真正需要留意的是不要在发布之后随意修改epoch值否则所有已生成的ID和后续ID会出现在相同位区间内直接造成时间戳乱序甚至重复。1.3 位运算的作用不只是炫技你会看到所有雪花ID实现里都充满左移、按位或、按位与操作。用位运算而不是“把三段分别转成字符串再拼接”有两个核心原因第一性能。位运算直接操作long不涉及字符串对象创建也不涉及除法取模。生成一个ID只做几次位移和或运算耗时可以低至几十纳秒。第二最终结果保持数值形态。ID可以直接作为long类型传给数据库、缓存和消息队列不需要做类型转换也不会出现字符串拼接带来的额外存储开销。举个例子workerId 12就是把10位机器ID放到序列号腾出的低12位之上(currentTimestamp - epoch) 22则是把时间戳整体抬高到高位。最后用|把三段合到一起比任何字符串拼接都干净利落。2. 手写一个不依赖第三方库的生成器2.1 类的基本骨架与两个关键构造参数写一个可用的单机版雪花ID生成器核心类是清晰的。首先定义三组常量序列号位数、机器ID位数、以及它们的最大值。接着定义两个实例变量workerId和epoch。public class SnowflakeIdGenerator { private static final long SEQUENCE_BITS 12L; private static final long WORKER_ID_BITS 10L; private static final long MAX_SEQUENCE ~(-1L SEQUENCE_BITS); private static final long MAX_WORKER_ID ~(-1L WORKER_ID_BITS); private static final long WORKER_ID_SHIFT SEQUENCE_BITS; private static final long TIMESTAMP_SHIFT SEQUENCE_BITS WORKER_ID_BITS; private final long workerId; private final long epoch; private long lastTimestamp -1L; private long sequence 0L; private final Object lock new Object(); }epoch是自定义的时间起点通常取一个稳定的过去时间点比如系统上线日期。不要默认取1970-01-01因为那样41位时间戳会在2021年前后很快耗尽高位空间导致负数或溢出。把时间起点后移相当于为时间戳位段“续命”。workerId的合法性校验很关键。10位机器ID最多支持1024个节点超出范围一定要直接抛异常而不是静默截断。生产环境里因为配置错误导致两个节点拿到同一个workerId很长一段时间内都无法发现直到出现重复ID才追悔莫及。2.2 生成ID的核心逻辑时钟判断、序列号自增、位拼接生成一个ID的大致流程拿到当前毫秒时间戳如果当前时间戳小于上次生成ID的时间戳说明发生了时钟回拨如果当前时间戳等于上次的时间戳序列号加一序列号溢出说明这一毫秒已经用掉4096个ID需要等待下一毫秒如果当前时间戳大于上次时间戳序列号归零保存当前时间戳拼接并返回ID。这里最容易被忽略的是序列号溢出判断。当sequence 4095再加1得到4096执行(sequence 1) MAX_SEQUENCE之后会变成0。所以不能只用结果必须立刻判断结果为0时进入等待下一毫秒的逻辑。2.3 完整Java实现一个可直接拷贝的版本下面是一份我实际压测过的实现不依赖任何第三方库可直接复制到项目里使用public class SnowflakeIdGenerator { private static final long SEQUENCE_BITS 12L; private static final long WORKER_ID_BITS 10L; private static final long MAX_SEQUENCE ~(-1L SEQUENCE_BITS); private static final long MAX_WORKER_ID ~(-1L WORKER_ID_BITS); private static final long WORKER_ID_SHIFT SEQUENCE_BITS; private static final long TIMESTAMP_SHIFT SEQUENCE_BITS WORKER_ID_BITS; private final long workerId; private final long epoch; private long lastTimestamp -1L; private long sequence 0L; private final Object lock new Object(); public SnowflakeIdGenerator(long workerId, long epoch) { if (workerId 0 || workerId MAX_WORKER_ID) { throw new IllegalArgumentException(workerId must be in [0, 1023]); } this.workerId workerId; this.epoch epoch; } public long nextId() { synchronized (lock) { long currentTimestamp System.currentTimeMillis(); if (currentTimestamp lastTimestamp) { long backOffset lastTimestamp - currentTimestamp; if (backOffset 10) { throw new IllegalStateException( Clock moved backwards. Refusing to generate id for backOffset ms); } // 小范围回拨等待时间追平 while (currentTimestamp lastTimestamp) { currentTimestamp System.currentTimeMillis(); } } if (currentTimestamp lastTimestamp) { sequence (sequence 1) MAX_SEQUENCE; if (sequence 0) { currentTimestamp tilNextMillis(lastTimestamp); } } else { sequence 0L; } lastTimestamp currentTimestamp; return ((currentTimestamp - epoch) TIMESTAMP_SHIFT) | (workerId WORKER_ID_SHIFT) | sequence; } } private long tilNextMillis(long lastTimestamp) { long current System.currentTimeMillis(); while (current lastTimestamp) { current System.currentTimeMillis(); } return current; } }代码里有几个细节值得逐行说清楚。MAX_SEQUENCE ~(-1L SEQUENCE_BITS)等价于(1 12) - 1也就是4095。为什么不用普通数字常量因为一旦调整位段长度最大值会自动跟着变不容易写错。(sequence 1) MAX_SEQUENCE是经典的“环形序列”写法。当sequence等于4095时加1后变成4096二进制为1000000000000与1111111111111按位与后为0。这种写法的好处是序列号永远不会超过4095也不需要额外if判断“是否大于MAX”。workerId WORKER_ID_SHIFT里的WORKER_ID_SHIFT等于12因为序列号占12位机器ID必须往左移动12位才能给序列号腾出空间。同理时间戳要往左移12 10 22位。2.4 边界场景的单元测试怎么设计写完生成器立刻要补几类测试否则上生产很容易翻车连续生成1万个ID断言全部不同同一毫秒内生成5000个ID断言不重复且耗时在合理范围将System.currentTimeMillis()在测试中模拟回拨断言抛出异常或进入等待逻辑校验workerId超过1023时抛异常校验生成的ID为正数且后12位与序列号逻辑对得上。我习惯在测试里故意把epoch设置成当前时间再加100年观察是否出现负数或异常。这种极端测试看起来无厘头却能最快暴露位移溢出问题。3. 真正上生产前这四个坑必须先填3.1 时钟回拨重复ID的真正来源与落地对策服务器上的时间并不是绝对可靠的。运维同学做NTP时间同步、手工调整系统时间、甚至虚拟机休眠恢复都可能让System.currentTimeMillis()往回跳。一旦时间戳倒退而生成器已经把那段未来时间序列里的ID发出去了再生成新ID就会和旧ID在“时间戳机器位”完全一致序列号又从0开始于是出现重复。我的处理策略分三级回拨小于10毫秒不直接拒绝而是让线程自旋等待直到系统时间追平上次的时间戳回拨在10毫秒到200毫秒之间清空序列号并重新初始化同时记录告警日志提示运维检查时间源回拨超过200毫秒直接抛异常停止对外发放ID避免静默产生重复数据。这套策略没有标准答案完全取决于业务对中断和重复的容忍度。如果服务是晚上低峰期发布允许短暂拒绝请求如果是全天候交易链路最好把200毫秒阈值再拉低宁可快速失败也不能重复。3.2 workerId分配配置文件、数据库还是注册中心10位机器ID上限是1024但怎么把唯一的workerId发给每个节点才是真正的难题。最省事的是部署时通过环境变量或配置文件下发。一个典型的启动命令长这样java -jar order-service.jar --worker.id23这种做法简单直接但人工分配容易漏配、错配。我有一次就在测试环境把两个实例配成了同一个workerId当天排查重复订单整整花了一个下午。进阶做法是让节点启动时去数据库申请一段workerId。比如用一张表记录worker_id和last_update_time节点启动时读取当前最大值并加1。缺点是一旦节点重启过频表记录会疯涨而且有单点依赖。更稳妥的方案是借助注册中心。节点启动时向注册中心申请一个临时节点用节点序号作为workerId节点下线后释放重启时优先复用旧ID。这个方案对运维体系有要求但长期来看最省心。分配方式优点缺点配置文件/环境变量实现简单、无外部依赖人工分配易出错、扩容麻烦数据库自增分配可靠、可审计依赖数据库可用性、重启导致浪费注册中心临时节点动态分配、自动回收需要引入额外组件3.3 单毫秒并发超过4096怎么办12位序列号决定了单机单毫秒最多生成4096个ID。在大多数业务场景单机每毫秒4096的并发已经很高折合每秒409.6万个完全够用。但电商秒杀、消息中间件大流量写入这类场景确实可能出现单毫秒峰值高于4096的节点。解决办法有几个方向。最粗暴的是把序列号位数从12位扩到13位或更多同时压缩机器ID位数。如果你只需要支撑64个节点完全可以把workerID从10位降到6位把省下的4位给序列号。这样单毫秒可以生成16384个ID单机每秒1600万绰绰有余。另一个思路是允许多个生成器实例同时服务。比如把业务ID拆成“业务前缀雪花ID”不同业务线使用不同的workerId区间不必共享同一个4096池。这个思路在分库分表场景尤其常见。3.4 JS精度丢失、日志序列化和long类型直出雪花ID是64位long大于JavaScript的Number.MAX_SAFE_INTEGER2^53 - 1。前端ajax拿到这个ID直接把数字解析成Number尾部精度就会丢具体表现是后几位变成0导致操作对象错乱。如果你有前端联调后端接口一定不能直接返回数字格式的ID。最简单的方案是把long格式化成字符串返回。通常有两种做法一种是对外REST接口全部返回字符串另一种是统一在配置中心指定Jackson序列化策略让所有long字段自动转为字符串。日志里也要注意。用Long.toString(id)输出完整ID没有任何问题但如果粗心把它当成int打印就会出现负数或截断。建议在日志框架里对ID统一做类型标注方便排查问题时直接根据ID反查时间戳和workerId。4. 性能调优从“够用”到“单机百万级”4.1 为什么synchronized会成为瓶颈我最初实现的版本加了synchronized锁因为生成器内部的sequence和lastTimestamp必须保证线程安全。但锁在这里其实没有太大必要——真正需要互斥的只是一个毫秒窗口内的几百次操作锁粒度太粗会放大争用。做一个粗糙压测对比单线程调用的差异还不明显一旦变成4线程甚至8线程同时调用synchronized版本因为锁的阻塞唤醒吞吐量会明显下降。很多生产系统之所以会用预生成或CAS方案就是为了对抗这种锁竞争。4.2 三种优化手段CAS、ThreadLocal与预取第一种是去掉对象锁改用AtomicLong维护序列号。每次生成时用compareAndSet更新lastTimestamp和sequence但实现复杂度会上升因为要考虑两个变量同时更新的原子性需要封装成一个不可变快照对象。第二种是ThreadLocal版本。每个线程独自维护一份lastTimestamp和sequence生成ID时不需要和其他线程竞争。代价是ID的全局绝对顺序就不再严格单调了——同一毫秒内线程A生成的ID可能比线程B生成的ID晚但不同毫秒之间依然保持时间序。对绝大多数业务这个程度的乱序完全可接受。第三种是批量预取。一次锁内生成N个ID存入本地队列后续请求直接从队列取。队列空了再去锁内批量补充。这个方案特别适合数据库批量插入场景既能降低锁竞争又能减少System.currentTimeMillis()调用次数。4.3 实测数据不同方案在压测下的差异我在一台8核16G的普通云服务器上做过一轮粗糙测试生成1000万次ID的大致数据如下实现方式线程数耗时毫秒每秒吞吐万synchronized逐条生成11210826synchronized逐条生成44280233ThreadLocal分段生成11040961ThreadLocal分段生成41720581批量预取100个/次41120892数据不严谨不同机器差异很大但趋势很明显锁竞争和时钟调用是主要开销。优化到每秒几百万之后继续优化意义不大因为数据库连接池、网络I/O早就成为瓶颈了。4.4 监控什么指标才能避免线上两眼一抹黑生产环境一定要给生成器加监控至少四个指标每分钟生成ID总数看流量趋势单毫秒序列号使用峰值判断是否接近4096上限时钟回拨次数和最大回拨毫秒数等待下一毫秒的累计耗时。我习惯把这几个指标以日志形式输出再接入监控系统。回拨次数达到阈值就告警比事后从数据重复里发现要省心太多。5. 雪花ID的变体与二次改造5.1 业务需要更短的ID压缩位段或使用字符编码标准雪花ID是19位十进制数字作为订单号会偏长。很多业务希望ID尽可能短方便人工记忆和客服系统录入。一种变体是把时间戳改为秒级这样时间戳位数可以从41位降到31位左右同时把机器ID和序列号压缩得到一个更短的long。代价是每秒能生成的ID数量大幅下降。如果单机每秒只需几万个ID秒级时间戳完全够用。另一种常见做法是把64位long再做一次进制转换比如转换成62进制字符串可以将19位数字压缩成11位左右。这类方案并非标准雪花ID但保留了“趋势递增”的特性适合短链、优惠券码等场景。5.2 前端拿不到精确ID对外统一字符串化前面提过的JS精度问题值得再单独强调一次。如果接手过老系统你会发现后端的long通过JSON序列化传到前端已经变成123456789012345670这种末尾归零的错误值。正确解法不是让前端改用BigInt而是后端主动兼容。用String接收和返回ID最干净。数据库主键仍可以是bigint不影响索引性能但DTO、接口层的类型必须改成字符串。5.3 需要从ID里反解时间把时间起点调近有些统计需求希望从订单号里直接看出“哪一天下的单”比如客服拿到的ID能快速识别归属时间段。这时候可以把epoch偏移量设置成“当年1月1日”这样时间戳段位数不变但对时间的解读更直观。也可以进一步把字节段重排前几位放日期后面放机器ID和序列号。这种非标准结构完全可以自定义只要保证全局唯一且单调递增即可。5.4 多系统共用一套ID空间高位预留业务标识如果你的公司有多个核心系统订单、支付、退款都需要用统一ID且要求全局不重复可以在标准雪花ID的机器ID位之上再腾出2到4位作为“业务域标识”。比如值0代表订单、1代表支付、2代表退款。这样每个系统虽然各有独立的生成器但ID的最高位段不同保证了跨系统唯一。同时还保留了时间趋势数据入湖后还能根据ID里的业务标识快速路由一举两得。6. 选型之前什么场景不适合雪花ID说了这么多雪花ID的好话也该聊聊反方观点。我见过不少团队把雪花ID当成万能药其实它有明显的边界。第一严格审计型系统慎用。雪花ID单调递增意味着外部能通过ID差值估算业务量。如果你的订单量是商业秘密用随机UUID反而更安全。第二时钟源不稳定的小型设备慎用。没有NTP、硬件时钟经常不准回拨问题会频繁触发。这类场景更适合由中心化服务统一发号或者使用数据库号段模式。第三已经在用成熟号段模式的团队不必强行迁移。号段模式从数据库取一段连续ID性能同样很高还能方便地做业务拆分。雪花ID真正擅长的是多节点、无中心、需要全局趋势递增的场景。第四纯展示型数据的ID不需要复杂方案。比如评论、点赞这类高频写入但不关心顺序的数据UUID或随机数反而省事。我在现在的项目里订单、支付、库存等核心链路用雪花ID辅助业务用UUID两类ID各司其职。选型的本质不是比哪个算法更先进而是看你的系统部署形态、一致性要求和运维能力。最后再分享一个实战小技巧如果你的生成器节点数经常变动相比依赖环境变量我更推荐把workerId放到配置中心统一维护。启动时从配置中心拉一次失败则快速失败不要默认取本机IP或MAC做hash因为容器环境下这两个值经常不可靠。雪花ID生成器看着不起眼但所有细节都是在重复和乱序的教训里逼出来的。希望这篇实操记录能帮你少走我当时踩过的弯路。