# 

挑分布式 ID 方案时，讨论往往集中在每秒能发多少号。但真正决定方案能否长期用的，是对时钟的依赖程度，以及有没有中心节点。

## UUID v4 做主键为什么会让索引变慢？

现行的 UUID 标准是 2024 年 5 月发布的 RFC 9562，取代了旧的 4122，新增 v6、v7、v8。

新标准里对 v4 有一段直接评价：非时间有序的 UUID 索引局部性很差，连续生成的值彼此不相邻，插入会落在随机位置。

这就是随机主键的代价：写入散落在 B+ 树各处，页面反复分裂，填充率降低，写放大明显。v7 的思路是把毫秒时间戳放在最高位，兼顾唯一性和趋势递增。不过它的默认实现在同一毫秒内并不保证单调，要严格单调得显式使用计数器。

## 雪花算法的 64 位够用多久？

结构是固定的四段，每一段的作用都能算清楚。

```text
1 位符号位   固定为 0，保证 ID 为正数
41 位时间戳  毫秒级
10 位机器 ID 支持 1024 个节点
12 位序列号  每毫秒每节点 4096 个
```

41 位能表示的毫秒数是 2 的 41 次方，约 69.7 年。单节点理论上限约 409 万个每秒。

这个上限的前提是每一毫秒都打满、时钟稳定推进。而且它是单节点数字。

原始实现的项目仓库早已归档退役，现在的都是各家二次实现。更值得注意的是纪元起点没有统一标准，各家自选，同一个整数解出来的时间完全不同。

## 时钟回拨要分几档处理？

时间戳取自墙上时钟，而它会被校时、人工改时间、虚拟机挂起恢复这几类事件往后拨。时间一旦变小，同一节点就可能重新生成刚用过的组合。

| 回拨量级 | 处置方式 | 代价 |
| --- | --- | --- |
| 毫秒级 | 等待时钟追平 | 阻塞调用线程，高并发下形成尖刺 |
| 十毫秒到一秒 | 预支未来时间或借用预留位 | 实现复杂，要保证全局单调 |
| 秒级以上 | 直接拒绝服务并报警 | ID 服务不可用，业务必须能容忍 |

反解生成时间的方式很简单。

```java
long unixMs = (id >> 22) + epoch;
```

完全不依赖时钟的方案也存在，代价是失去「ID 内含时间」这个特性。在机器启动时校验本机时间与集群时间差、超阈值直接拒绝启动，是常见的第一道防线。

## 闰秒到底会不会导致回拨？

正闰秒本质上是「多一秒」，不是回退。但不同系统实现不同，可能表现为同一秒内时间戳重复、时间不前进。真正的回退发生在负闰秒，而负闰秒至今没有发生过。

行业上最常用的规避方式是摊薄：把这一秒在整整一天里均匀分摊掉，永远不出现多出来的那一秒。副作用是不同厂商的时钟在窗口期内可能差到接近一秒，跨厂商比较时间戳会出错。

废除闰秒的进展也容易写错。2022 年国际计量大会的决议是提高容差上限、不再按固定阈值插入，时间点是最迟不晚于 2035 年，不是 2035 年直接废除，方案至今还在审议。

## 号段模式和雪花算法的取舍在哪？

号段模式一次从数据库取一批放进内存里发，正常路径完全不碰数据库。

关键在于双缓冲：当前号段下发到一定比例时就异步加载下一段，避免用尽时才取造成阻塞。业界经验是把段长设成高峰发号量的 600 倍，数据库短时不可用也能撑十到二十分钟。

取舍很清楚：雪花算法无中心、每次生成不需要网络往返，但强依赖时钟，时钟一乱就重号或拒服务；号段模式不依赖时钟，但要引入中心，且 ID 能反推出单位时间发号量。

选型对比和纪元取值属于会长期沿用的约定，值得留一档记录。

```bash
# ID 方案选型对比、纪元取值、workerId 分配表，统一留一档
# 这份选型记录我用墨衍同步到团队文档，新服务接入时直接对照
```

## ID 传到前端为什么会丢精度？

JavaScript 的数字类型是双精度浮点数，能精确表示的整数上限是 9,007,199,254,740,991，也就是十六位数字。

```javascript
JSON.parse('{"id": 9007199254740993}').id
// 实际得到 9007199254740992，且不报任何错
```

这个范围远小于 64 位整数，超出部分会被静默舍入。通用处置是后端直接序列化成字符串，或前端改用大整数类型解析。

还有两个变种值得留意：机器 ID 靠手工配置在集群扩大后极易冲突，而这种重号没法靠时钟检测发现；ID 内含时间信息在订单类场景是信息泄漏，能被拿来推算业务量。


挑分布式 ID 方案时，讨论往往集中在每秒能发多少号。但真正决定方案能否长期用的，是对时钟的依赖程度，以及有没有中心节点。

分布式 ID 怎么选？分水岭其实不是性能

编程语言

架构设计

数据库

分布式ID方案的核心矛盾在于时钟依赖与中心节点的取舍。UUIDv4随机性导致B+树索引写入散乱、页面分裂，性能差；UUIDv7将毫秒时间戳置于高位实现趋势递增。雪花算法64位结构约支持69.7年，单节点上限409万/秒，但依赖稳定时钟且纪元不统一。时钟回拨需分级处理：毫秒级等待、秒级预支或拒绝。号段模式不依赖时钟但需中心节点，双缓冲可缓解压力。前端JS处理64位ID需转字符串防精度丢失。

代码解释

虚拟机

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

分布式ID方案的核心矛盾在于时钟依赖与中心节点的取舍。UUIDv4随机性导致B+树索引写入散乱、页面分裂，性能差；UUIDv7将毫秒时间戳置于高位实现趋势递增。雪花算法64位结构约支持69.7年，单节点上限409万/秒，但依赖稳定时钟且纪元不统一。时钟回拨需分级处理：毫秒级等待、秒级预支或拒绝。号段模式不依赖时钟但需中...

分布式 ID 怎么选？分水岭其实不是性能-腾讯云开发者社区-腾讯云

分布式 ID 怎么选？分水岭其实不是性能

分布式 ID 怎么选？分水岭其实不是性能

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐