目录
⚙️ 1. UUID (Universally Unique Identifier)
📊 分布式ID方案核心指标对比
| 方案 | 唯一性 | 有序性 | 吞吐量 | 存储空间 | 自治性 | 典型场景 |
|---|---|---|---|---|---|---|
| UUID | 全局唯一 | 完全无序 | 300万/秒 | 128位 | 完全自治 | 会话ID、临时文件 |
| Snowflake | 全局唯一 | 趋势递增 | 409.6万/秒 | 64位 | 依赖时钟 | 订单ID、日志追踪 |
| 美团Leaf | 全局唯一 | 本地单调递增 | 5万+/秒 (远程) | 64位 | 弱依赖DB | 金融交易、高可用系统 |
| 百度Uid | 全局唯一 | 时间趋势递增 | 600万+/秒 | 64位 | 依赖RingBuffer | 高并发写入场景 |
| CosId | 全局唯一 | 本地严格递增 | 1.27亿+/秒 | 64位 | 灵活依赖存储 | 分库分表、极致性能需求 |
🔍 分方案深度解析
⚙️ 1. UUID (Universally Unique Identifier)
原理：基于MAC地址、时间戳、随机数拼接后哈希生成128位标识符（如
123e4567-e89b-12d3-a456-426614174000）。优点：无中心节点、生成简单、全球唯一。
缺点：
长度大：128位存储效率低，数据库索引膨胀；
完全无序：导致数据库插入频繁页分裂，性能骤降；
安全隐患：版本1可能泄露MAC地址。
适用场景：临时令牌、文件命名、非数据库主键场景。
❄️ 2. Snowflake (Twitter开源)
- 官网：https://github.com/twitter/snowflake
原理：64位ID = 时间戳(41位) + 机器ID(10位) + 序列号(12位)，实现本地生成。
优点：
趋势递增：利于数据库B+树索引优化；
高性能：单机可达409.6万ID/秒。
致命问题：
时钟回拨：服务器时间倒退导致ID重复（需人工干预）；
机器ID管理难：动态扩缩容时需保障ID唯一性。
改进方向：Leaf-Snowflake 通过ZK缓存workerId弱依赖。
☘️ 3. 美团Leaf
号段模式
原理：预分配ID段（如[1,1000]），内存分发，异步更新数据库。
优化演进：
双Buffer：DB故障时无缝切换备用号段，实现高可用5；
动态Step：根据QPS自动调整号段长度（如QPS↑ → Step×2）。
性能：远程调用QPS 5W+，TP99 <1ms。
Snowflake模式
解决workerId依赖：ZK分配 + 本地缓存，宕机时降级使用历史workerId。
🔄 4. 百度UidGenerator
- 源码地址：https://github.com/baidu/uid-generator
核心改进：
RingBuffer预缓存：提前生成ID填充环形队列，并发取号时无锁；
借时机制：当前毫秒序号耗尽时，“借用”未来时间戳继续生成。
局限：
默认时间戳仅支持8.7年（41位设计）；
WorkerId复用策略缺失，扩容受限。
🚀 5. CosId
- 官网：SegmentId | CosId
架构创新：
SegmentChainId：无锁号段链，基于饥饿状态动态扩容安全距离，吞吐达1.27亿/秒；
SnowflakeId增强：解决时钟回拨、机器号动态分配、分片不均问题；
多存储支持：JDBC/Redis/ZooKeeper号段分发器，适配不同基础设施。
💎 选型建议
简单轻量 → UUID（非数据库场景）；
有序性与性能平衡 → Snowflake/Leaf-Snowflake（需解决时钟问题）；
高可用容忍DB故障 → Leaf号段模式（双Buffer容灾）；
极致性能需求 → CosId（无锁号段链）；
长期运行系统 → 慎用百度Uid（注意时间戳耗尽问题）。
💡 分布式ID的本质是权衡：唯一性、有序性、性能与运维复杂度需结合业务流量、数据库架构及运维能力综合决策。新一代方案如CosId通过架构创新显著提升性能边界，是分库分表等高并发场景的优选