雪花算法：分布式世界的“身份证号”

嘿朋友想象一下你是一家拥有几千台服务器的互联网大厂架构师。现在有个小麻烦你的订单系统每秒钟要生成几万个订单号。如果让数据库自己搞自增ID几台数据库凑在一起肯定会出现“撞车”——大家都生成了ID1001这就像两个新生儿都叫“张三”户籍科数据库当场就得炸毛。这时候Twitter 的那帮天才掏出了一个叫雪花算法的宝贝。这玩意儿生成的 ID 不长还是个数字但就像雪花一样世界上没有两片完全相同的雪花。它是怎么做到的呢全靠“拼积木”。核心原理把时间、地点、序号拼成“身份证”雪花算法生成的 ID 是一个64 位的长整型数字在 Java 里是long类型。这 64 位并不是随机乱填的而是像切蛋糕一样被切成了几块每一块都有特殊的含义。我们可以把它看作一张“数字身份证”积木块位数含义通俗解释符号位1 位固定为 0我是好人保证生成的 ID 是正数别搞成负数吓唬人。时间戳41 位毫秒级时间出生时间记录你出生的精确时刻精确到毫秒。机器ID10 位数据中心机器籍贯/住址你是北京机房 3 号服务器生的还是上海机房 1 号生的。序列号12 位自增数字同毫秒排行如果同一毫秒生了好几个那就排号001, 002, 003...为什么这样拼就不会重复这就好比给新生儿起名时间不同只要你不是穿越回来的时间戳肯定不一样ID 就不一样。机器不同就算时间一样同一毫秒你是 1 号机器生的我是 2 号机器生的机器 ID 不同ID 也不一样。序号不同就算时间一样、机器也一样高并发那咱们就排号你是老大我是老二序号不同ID 还是不一样。结论只要机器 ID 不冲突这 ID 就绝对全局唯一它的“超能力”为什么大家都爱它趋势递增数据库的最爱因为 ID 的高位是时间戳时间是往前走的所以 ID 总体上也是越来越大的。好处数据库尤其是 MySQL 的 InnoDB 引擎最喜欢自增的主键。如果你用 UUID乱码一样的字符串数据库索引会分裂性能掉渣。用雪花算法数据库写入速度嗖嗖的就像排队买票一样井然有序。高性能闪电侠生成这个 ID 不需要去查数据库也不需要去请求 Redis。它纯粹是内存计算靠的是位运算左移、或运算。速度单机每秒能生成百万级的 ID。这就好比你不需要去派出所办证自己在家里拿个印章盖一下就算数了快得离谱。简单粗暴不依赖任何第三方服务Zookeeper、Redis 等只要给每台机器分配个编号代码里算一算就完事了。它的“阿喀琉斯之踵”时钟回拨虽然雪花算法很完美但它有一个致命的弱点它是个“时间控”。它强依赖服务器的时间。如果有一天你的服务器因为 NTP 时间同步或者其他原因时间突然往回拨了比如从 12:00:05 变成了 12:00:01那就会出大事后果机器可能会用“过去的时间”生成一个已经生成过的 ID导致ID 重复。解决暴力派一旦发现时间回拨直接抛出异常拒绝服务“别干了时间乱了我罢工”。温和派如果发现回拨时间很短比如几毫秒就稍微等一等等时间追上来再生成。逛一逛ID 生成博览会方案核心原理优点缺点槽点适合场景UUID随机字符串本地生成极快不依赖外部太长、无序数据库索引噩梦临时文件、日志 ID、非主键数据库自增单表auto_increment简单天然有序单点故障并发低扩展难只有单库的小项目Redis 自增INCR命令性能好天然有序依赖 Redis持久化没做好会丢号订单流水号、计数器号段模式批量取号内存发号数据库压力小容灾强依赖数据库ID 连续易被爬取核心业务美团 Leaf、滴滴 TinyID百度 UidGenerator雪花改良环形缓存性能怪兽QPS 600万依赖 Zookeeper配置复杂超高并发场景详细解说各路神仙显神通UUID随性的“流浪艺术家”原理基于 MAC 地址、时间戳、随机数生成的一串 32 位的字符串如550e8400-e29b...。槽点太长存一个 ID 占 36 个字符比bigint多花好几倍空间。无序插入数据库时索引树会频繁分裂就像把书随机插进书架得不停挪位置写入性能极差。评价除非你不需要存数据库或者只是用来做临时文件名否则别拿它当主键。2. 数据库自增老旧的“户籍科”原理利用 MySQL 的auto_increment。为了防冲突可以设置步长比如库 1 每次加 2库 2 每次加 2 但起始是 2。槽点单点瓶颈所有 ID 请求都打向数据库数据库挂了全系统瘫痪。扩展难想加机器得重新规划步长还得停机维护。评价适合还在“作坊式”开发的小项目大厂早就抛弃了。3. Redis 自增高效的“打号机”原理利用 Redis 的单线程原子性执行INCR key命令。优点速度极快内存操作生成的 ID 还是连续递增的。槽点依赖 RedisRedis 挂了ID 生成也就停了。数据丢失风险如果 Redis 重启时 RDB/AOF 没持久化好ID 可能会重复比如重启后又从 1 开始计数。评价适合做“流水号”如202310270001配合日期前缀使用效果更佳。4. 号段模式聪明的“批发商”这是目前大厂美团、滴滴非常流行的方案也是雪花算法的强力竞争者。原理应用启动时去数据库批量申请一段 ID比如 1 到 1000存在本地内存里。发 ID 时直接从内存里拿拿完了再去数据库申请下一段1001 到 2000。双 Buffer 机制为了防止申请下一段时卡顿通常会搞两个缓冲区A 和 B。A 快用完时后台线程悄悄去把 B 填满。A 用完瞬间切换到 B用户体验不到卡顿。优点数据库压力极小原来每生成一个 ID 都要写库现在每 1000 个才写一次。容灾强就算数据库挂了本地内存里还有几百个 ID 能发够撑一会儿让运维去修了。代表选手美团 Leaf支持号段模式和雪花模式功能强大但依赖 Zookeeper 和 DB部署略重。滴滴 TinyID专注于号段模式支持双号段缓存简单好用。5. 百度 UidGenerator性能怪兽原理基于雪花算法改良但为了解决雪花算法“生成 ID 还要算时间”的微小耗时它搞了个RingBuffer环形缓冲区。绝招它像个“预生成工厂”后台线程不停地生成 ID 塞进环形队列里。业务线程要 ID 时直接从队列里纯内存读取连位运算都省了。QPS 能达到600 万非常恐怖。评价适合对性能有极致要求的场景但配置比较复杂得维护 Zookeeper。不想折腾只想快点上线用Redis 自增记得配好持久化。追求极致性能不怕配置麻烦用百度 UidGenerator。追求稳定业务量大且不想有单点故障用美团 Leaf号段模式。这是目前最推荐的通用方案。如果不怕时钟回拨的坑继续用雪花算法或者找个成熟的封装库如 Twitter 的 Snowflake 改进版。一句话建议如果是核心业务如订单、支付号段模式Leaf/TinyID是最稳妥的选择如果是日志、消息追踪雪花算法或UUID就足够了。号段模式你值得单开一栏之前也说了不过想再仔细一些的“空间换时间”和“批量换单次”的策略将原本需要频繁访问数据库的操作转化为了高效的本地内存操作战术一批量预取Batch Pre-fetching—— 减少数据库交互这是号段模式的基石。在高并发下如果每生成一个 ID 都去请求一次数据库数据库的锁竞争和网络 IO 会成为巨大的瓶颈。原理应用服务启动或号段耗尽时向数据库申请一段连续的 ID例如步长step1000申请1001~2000。效果原本需要1000 次数据库交互现在只需要1 次。这使得数据库的 QPS 压力降低了几个数量级即使后端数据库性能一般前端也能轻松抗住每秒数万甚至十万的请求。战术二本地内存分配Local Memory Allocation—— 极致性能拿到号段后ID 的生成过程完全在应用服务的本地内存中进行。原理服务在内存中维护一个当前号段如1001~2000和一个当前指针。每次请求 ID只需将指针1并返回无需任何网络 IO。效果内存操作的速度是纳秒级的这使得单机生成 ID 的 QPS 可以轻松突破10万甚至更高完全受限于 CPU 性能而非数据库性能。战术三双缓冲机制Double Buffering—— 消除等待如果等到号段彻底用完例如发到 2000才去申请下一段那么在申请新号段的几百毫秒内业务线程会被阻塞。为了解决这个问题号段模式引入了“双缓冲”或“异步预加载”。原理维护两个号段内存中同时持有“当前号段”和“下一个号段”。阈值触发当“当前号段”使用到一定比例例如80%即发到 1800时后台异步线程立即去数据库申请下一个号段2001~3000并加载到备用缓冲区。无缝切换当“当前号段”发完2000时直接切换到已经准备好的“下一个号段”业务线程零等待。效果彻底消除了因数据库网络延迟导致的业务阻塞保证了高并发下的平滑过渡。战术四数据库乐观锁Optimistic Locking—— 保证并发安全在多个应用实例集群部署同时向数据库申请号段时如何保证不拿到重复的号段原理利用数据库的UPDATE语句的原子性。-- 核心 SQL利用 update 的行锁和返回值 UPDATE leaf_alloc SET max_id max_id step WHERE biz_tag order;或者使用版本号机制乐观锁UPDATE id_generator SET max_id max_id step, version version 1 WHERE biz_tag order AND version old_version;效果即使有 10 个服务实例同时请求数据库也能保证只有一个实例的更新成功从而确保号段的全局唯一性。战术解决的问题核心手段批量预取数据库压力大一次拿 1000 个减少 IO 次数本地分配生成速度慢内存自增无网络开销双缓冲申请时阻塞80% 时异步预加载无缝切换乐观锁多实例冲突数据库行锁/版本号确保唯一号段模式通过“数据库做批发内存做零售”配合“提前备货双缓冲”成功将高并发的压力从脆弱的数据库转移到了高性能的本地内存中总结它是怎么工作的用一句口诀来概括雪花算法的一生“先看时间戳再查机器号同毫秒就排队拼起来拉倒”时间戳定先后保证趋势递增。机器号分你我保证分布式唯一。序列号防冲突保证高并发唯一。这就是雪花算法一个简单、高效、优雅的分布式 ID 生成方案