分布式系统中6个常用的“全局唯一标识”

1.数据库自增（步长分段）

• 原理：N 台 DB 机器，各设不同的起始值和固定步长 N。
• 示例：两台机器，步长 2，起始 1/2 → 1,3,5… 与 2,4,6…
• 优点：实现简单，天然递增。
• 缺点：扩容必须重新调整步长；写瓶颈在 DB；不具备高可用。

2.Redis INCR/INCRBY

• 原理：利用 Redis 单线程原子自增。可做成“日序”或“全局序”。
• 优点：10 万级 QPS 易达成，代码量少。
• 缺点：引入新组件；Redis 故障需主从/集群；持久化/重启要考虑丢号或跳号。

3.Snowflake（雪花算法）

• 结构：1 bit 符号位 + 41 bit 毫秒时间戳 + 10 bit workerId + 12 bit 序列号。
• 优点：单机每秒可生成 409.6 w 个有序 ID；64 bit 大小友好。
• 缺点：时钟回拨会重复；workerId 需要中心化分配（Zookeeper、DB、手动配置）。

4.ULID / UUID v7 / v8

• ULID：48 bit 毫秒时间戳 + 80 bit 随机 → 26 字符 Crockford Base32，可排序。
• UUID v7/v8：IETF 草案，128 bit，前 48/64 bit 为 Unix ms/ns，剩余随机。
• 优点：去中心化、按时间字典序、可读性优于 UUID v4。
• 缺点：128 bit 比 Snowflake 大一倍；目前库实现较新（Go oklog/ulid，Java ulid-creator 等）。

5.号段模式（Leaf、TinyID、UidGenerator）

• 思路：一次从 DB 或 Redis 批量拉取一段号（如 1000 个），本地内存原子分发，用完再拉。
• 美团 Leaf：DB 号段 + 双 buffer；支持高可用、动态扩缩容。
• 滴滴 TinyID：基于 MySQL 号段 + HTTP 服务。
• 百度 UidGenerator：雪花算法改良，workerId 由 DB 分配，时钟回拨可容错。
• 优点：QPS 高、对 DB 压力小。
• 缺点：需部署独立服务；号段用完前需异步预加载，否则抖动。

6.业务自定义拼接

• 示例：京东订单号 2025081212345678901 = 日期(8) + 秒级时间戳(5) + 用户尾号(3) + 随机(4)。
• 优点：人类可读，可隐藏信息量（防止爬虫）。
• 缺点：规则复杂，需保证各段不冲突；通常仍依赖 Redis/DB 做计数或锁。

选型速决

• 想要零依赖 → ULID / UUID v7
• 想要纯数字且最短 → Snowflake
• 想要最易落地 → Redis INCR（已有 Redis）或数据库步长（已有 MySQL）
• 想要10 万+ QPS 且高可用 → 号段模式（Leaf、TinyID）