一、雪花 ID 为何会诞生？（它解决的是真问题）

多机并行写而不想碰中心服务

• Twitter 当年把 MySQL 拆成上百分库，需要不重号又要本地生成。

• 依赖数据库自增/号段，就必须走中心锁或 RPC，延迟、单点都无法接受。

要求趋势递增

• 日志、消息流、分页排序、按时间回溯都很方便。

• 比 UUID 随机写造成的 B+Tree 随机插入好得多。

64-bit 整数

• 节省存储、网络，比 UUID（16 B 二进制 / 36 B 字符串）小得多。

• 前端不想带大串字符串；数据库索引页也更紧凑。

社区与语言支持成熟

• Java、Go、Rust、Node、Python、C++ 随手就有库。

• 主流云厂商（阿里、腾讯、AWS 洛神、GCP Firestore）都给了类似生成器。

─────────────────

二、为什么会被说“装 ×”？（雪花 ID 的适用区间被无限放大）

数据量（和并发）没有到需要

• 单机 MySQL 写入 5–10 W QPS 都可搞定；

• 并不存在“必须跨 20 台机器同时写表”；

→ 直接用数据库自增 + 唯一约束足矣。

没做任何「时钟回拨、workId 唯一化」治理

• 用着用着 NTP 回拨，ID 撞库，线上挂掉；

• 结果又回退到中心号段，与初衷背道而驰。

业务根本不需要“趋势递增”

• 只是保存日志或离线报表，随机 UUID 完全 OK。

• “永远不分页、永远只点查询”——雪花 ID 意义几乎为 0。

前端、第三方对 64-bit 精度不支持

• 结果又把 int 转成 string，在接口里到处是 “1234567890123456789”

• 最后既没省带宽，也没提升体验。

“能用就上”成了团队默认习惯

• 雪花 ID 看上去高级，新人也“无脑 copy”；

• 只要带分布式字眼的系统，就先把雪花 ID 搞一套。

─────────────────

三、到底什么时候“刚需”，什么时候“装 ×”？

指标 雪花 ID = 刚需 雪花 ID = 装 ×

写入节点数 ≥5 节点、还会水平扩 单机 / 双机

单表写 QPS ≥ 10 W / 秒 几千以内

必须按插入时间有序分页 是 否

不想运维中心号段服务 是 能接受

能否治理时钟＆workId 有人负责 没精力

业务寿命 > 40 年需要续约 是 否

满足左列 ≥3 条，雪花 ID 基本算“刚需”；

只有 1–2 条，且业务体量不大，用自增/UUID+映射表就很够，硬要雪花就有“装 ×”成分。

─────────────────

四、如果确实没到量级，用什么替代？

单机 / 单库：直接 AUTO_INCREMENT、SEQUENCE。

多库少并发：offset + increment（MySQL 双主常用）。

云原生、容器弹性：前缀 + 号段（Segment / Leaf）。

不需要递增、只要唯一：UUIDv4、NanoID、ULID、KSUID。

跨系统一次性迁移：映射表批量换键即可。

─────────────────

五、小结

• 雪花 ID 的诞生绝非“炫技”，而是 Twitter 时代的真实痛点。

• 但它确实被过度营销，动不动几十行业务代码就整一套发号器，带来时钟、前端精度、数据库热点等新的复杂度。

• 工程选型归根到底是成本 / 风险 / 价值平衡：

‑ 量级够、功能需要 → 上雪花，别犹豫；

‑ 量级小、能接受中心号段或自增 → 雪花往往是“装 ×”并埋雷。