全局唯一 ID：雪花算法与时钟回拨
2026/8/24大约 3 分钟
亿级规模系统系列 · 阶段 4 · 分库分表 · 第 25/49 篇 · 🚧 占位待学
上一篇：《水平拆分与分片键：一次选择，决定后半生》
下一篇：《跨分片难题：分页、聚合与跨库事务》
学习大纲：《QPS 过万与亿级消息系统设计学习总纲》
状态：待学习。 本文为占位文档：知识点清单、实验与验收标准已就绪，正文待按「先学习、先实验、再撰写」补全。
对应总纲单元：阶段 4 · 单元 4.4
一、本文要解决的问题
分库之后，各库自增 ID 必然冲突——ID 从数据库的免费午餐变成需要专门设计的组件。为什么不用 UUID？雪花算法 64 位怎么分配？机房时钟回拨了怎么办？ID 设计还藏着分片路由的心机（基因法载体）。
二、知识点清单
- 为什么不选 UUID：无序导致 B+ 树页分裂、36 字符太长、无业务语义
- 号段模式（美团 Leaf）：DB 批量发号段 + 内存分配，DB 挂了还能扛一段
- 雪花算法结构：1 符号位 + 41 时间戳 + 10 机器位 + 12 序列位，单机每毫秒 4096 个
- 时钟回拨问题：NTP 校时回拨导致 ID 重复；对策：等待 / 拒绝 / 扩展位记录回拨次数
- 机器位分配：静态配置 vs ZooKeeper / 数据库注册，机房与机器的编码
- ID 里埋业务语义：尾部嵌入分片基因（对接 4.3 基因法）、日期前缀的可读性取舍
三、动手实验（学习时必须真跑）
- 手写简化雪花算法（单机版），压测验证每毫秒序列位用尽时的自旋行为
- 模拟时钟回拨（改系统时间或 mock），复现重复 ID；实现「回拨小于阈值等待、大于阈值报错」对策
- 生成 100 万 ID，统计分布验证单调递增与毫秒内序号递增
四、验收标准（全部通过才进入下一篇）
五、写作提示（补正文时遵守）
- 开篇问题驱动；结构走「是什么 → 为什么 → 怎么做 → 背景知识」
- 所有代码、命令、输出必须先在本机跑通再写入，不得杜撰
- 版本口径以总纲环境清单为准（Spring Boot 3.x / MySQL 8.0 / Redis 8.x / RocketMQ 5.3.x / Kafka 4.3 / ShardingSphere 5.5.3）
- 涉及版本敏感结论时标注出处与时间
本篇完成后，把文首导航块的「🚧 占位待学」去掉，并在总纲处打卡。