Snowflake ID 在线解析器 - Twitter 风格 ID 解构

Snowflake ID 是 Twitter 在 2010 年开源的一种分布式唯一 ID 生成算法产生的 64 位长整型数字。它的核心思想是将 64 位分成多个段，分别存储时间戳、机器标识和序列号，从而保证在分布式系统中每个节点都能独立生成全局唯一的 ID，无需中心化协调。

因其形状像雪花、且 Twitter 内部项目代号为 "Snowflake" 而得名。目前被广泛应用于 Discord、Instagram、Twitter/X、字节跳动、美团 等平台的用户ID、消息ID生成。

Twitter 标准的 Snowflake ID 使用 64 位（实际有效 63 位，最高位为符号位恒为 0），划分如下：

• 第 63 位（1位）：符号位，始终为 0，保证 ID 为正数。
• 第 62–22 位（41位）：毫秒级时间戳，从自定义纪元（Twitter 为 2010-11-04）开始计算，可用约 69 年。
• 第 21–17 位（5位）：数据中心 ID，支持最多 32 个数据中心。
• 第 16–12 位（5位）：工作节点 ID，每个数据中心最多 32 个节点。
• 第 11–0 位（12位）：序列号，同一毫秒内最多生成 4096 个不同 ID。

理论 QPS 可达 409.6 万/秒（单节点），满足绝大多数业务场景。

提取方法：将 ID 右移 22 位（去除序列号12位 + worker5位 + 数据中心5位），然后加上纪元时间戳：

timestamp = (id >> 22) + EPOCH

其中 Twitter 纪元 EPOCH = 1288834974657（2010-11-04T01:42:54.657Z）。

本工具会自动完成此计算，并同时展示 UTC 时间、本地时间和相对时间。

总结：数据库主键场景推荐 Snowflake；需要完全去中心化时使用 UUID。

• Twitter / X：原始发明者，用于 tweet ID、user ID 等。
• Discord：纪元为 2015-01-01，用于消息ID、用户ID、频道ID。
• Instagram：使用变体，调整了位分配（时间戳+分片ID+序列号）。
• 字节跳动：基于 Snowflake 改进的分布式 ID 方案。
• 美团 Leaf：美团开源的分布式 ID 系统，支持号段模式和 Snowflake 模式。
• 百度 UIDGenerator：基于 Snowflake 的 Java 实现，支持缓存预取。

时钟回拨是 Snowflake 算法面临的经典问题：当服务器时钟因 NTP 同步等原因向后调整时，可能导致生成重复 ID。

常见解决方案：

• 等待恢复：检测到回拨后，阻塞等待时钟追上之前的时间。
• 备用时钟：记录上次生成时间，回拨时使用记录的时间继续递增。
• 扩展序列号：借用未来时间或扩展序列号位数来容纳回拨期间的 ID。
• 美团 Leaf 方案：使用 Zookeeper 持久化时间戳，回拨时拒绝服务并告警。

生产环境中需要结合监控告警和容错策略来应对此问题。

因为 Snowflake ID 趋势递增（基于时间戳），这对于数据库 B+Tree 索引非常友好：

• 新数据总是追加到索引末尾，减少页分裂。
• 相比 UUID 随机值，写入性能提升显著（可达数倍）。
• 8 字节存储空间比 UUID（16字节）节省一半，索引更紧凑。
• ID 中隐含时间信息，便于按时间范围查询和分片。

这也是为什么 MySQL 官方推荐使用单调递增的 ID 作为 InnoDB 主键。