分布式ID入门指南：如何在系统里生成唯一标识？

在你开发一个用户系统、订单系统或评论系统时，是不是都需要一个“ID”来标识数据？在单个数据库中，我们通常使用自增ID就行，但当你的系统越来越大，变成“分布式系统”时，自增ID就不够用了。

这时候，你就需要一种更强大的技术：分布式ID。

一、什么是分布式ID？

分布式ID（Distributed ID），指的是在多个系统、多个节点中生成的、不重复的、全局唯一的ID。

简单说：

不管你在哪个服务器、哪个服务节点生成 ID，都要保证“这个 ID 是唯一的”。

想象你有一个“订单编号生成器”，它必须在全球范围内、不同服务器上都不会重复——这就是分布式ID的使命。

二、为什么不能用数据库自增ID？

在小型项目中，我们经常使用数据库里的 AUTO_INCREMENT 自增主键生成ID。但在以下情况下就会出问题：

❌ 多库多表时：

不同数据库从1开始编号，可能会重复。

❌ 性能瓶颈：

每次生成ID都要访问数据库，速度慢、压力大。

❌ 没有排序或业务信息：

数据库ID无法表示“下单时间”或“哪个服务生成的”。

所以我们需要一个去中心化、性能高、不会冲突的 ID 生成方式。

三、分布式ID的基本要求

一个好的分布式ID，应该具备这些特点：

四、常见的分布式ID方案

下面是常见的几种生成分布式ID的方法，每种都有优缺点：

1. UUID（通用唯一标识符）

• 格式示例：f47ac10b-58cc-4372-a567-0e02b2c3d479
• 优点：简单快速，完全唯一
• 缺点：太长（36位），无序，不适合数据库索引

适用场景：简单唯一标识，但不追求性能或排序

2. 数据库号段方式

• 中心数据库维护一张“号段表”，每个节点一次性申请一段ID，比如从10000到20000。
• 节点本地缓存号段，自主生成ID。

优点：简单，ID短，适合单集群系统
缺点：需要中心协调，扩展困难，存在单点故障

3. Redis/缓存生成ID

• 利用 Redis 的 INCR 命令快速生成ID
• 每个服务请求 Redis 获取唯一ID

优点：高性能，易实现
缺点：依赖 Redis，存在网络和故障风险

4. 雪花算法（Snowflake）

这是 Twitter 开发的一种经典分布式ID方案（可参考前一篇文章），特点是：

• 基于时间戳生成，有序性好
• 组合了时间、机器编号、序列号
• 本地生成，不依赖数据库

优点：高性能、唯一、可排序
缺点：实现稍复杂，系统时间回拨会导致问题

5. 号段 + 本地缓存混合方案

• 中心服务一次性发放一个时间窗口内的 ID 规则（如每天的起始号段）
• 各节点基于规则自主生成ID

优点：兼顾灵活性和安全性
缺点：实现稍复杂，需控制号段冲突

五、分布式ID的组成结构（以雪花算法为例）

一般来说，一个分布式ID会包含这些组成部分：

例如，订单ID以“8”开头，用户ID以“1”开头，就可以快速区分业务来源。

六、分布式ID的使用场景

• 电商订单号生成
• 评论/点赞记录ID
• 用户ID、会话ID
• 日志追踪、链路ID
• 数据库存储主键（MySQL、MongoDB）

七、初学者学习建议

• 了解 UUID、雪花算法、数据库自增ID 的优缺点
• 试着用 Redis 的 INCR 自己写一个 ID 生成服务
• 学会用开源工具如 Baidu 的 UidGenerator、美团的 Leaf 等
• 了解“时间戳 + 机器编号 + 自增序列” 的 ID 组合方式

分布式ID 是分布式系统的基础组件，它帮助我们在没有中心数据库的情况下，依然能够高效、安全地生成唯一标识。

它看起来只是一个“数字”，背后却体现了系统设计、性能优化和架构思维。掌握分布式ID的原理和实现，对初级开发人员是一次重要的架构思维训练。