解锁分布式唯一 ID：技术、实践与最佳方案

一、先搞懂：为啥需要 “分布式唯一 ID”？

平时咱们用手机下单、发消息，每个订单、每条消息都得有个 “专属编号”—— 比如订单号20241018123456，得保证全平台就这一个，不能跟别人重复。

以前系统小，用数据库 “自增 ID” 就行（比如 1、2、3、4 按顺序排）。但现在系统变大了，数据要拆成好几个库（比如北京库、上海库），每个库都按 1、2、3 自增，就会出现 “两个库都有 ID=5” 的情况 —— 这就乱了！

所以得有个 “全局发号器”，不管数据存在哪个库、哪个服务器，生成的 ID 全平台唯一。这就是 “分布式唯一 ID” 的作用。

二、好的分布式 ID，得满足 4 个要求

不是随便生成个号就行，业务有硬规矩：

（一）必须唯一：最基本的底线

比如订单 ID，要是重复了，俩用户的订单弄混，商家发错货、财务算错账，麻烦就大了。这是 ID 的 “生命线”。

（二）最好按顺序涨：方便存储和查询

比如 ID 从 1001 涨到 1002，再到 1003，数据库存的时候能按顺序排，查数据更快；要是 ID 一会儿 1001、一会儿 9999、一会儿 200，数据库就得来回挪数据，变慢。

（注：“趋势递增” 就行，比如 1001、1003、1005，不用严格连续，差几个没关系）

（三）别太有规律：防止被 “扒信息”

要是订单号按202410180001、202410180002连续排，竞品一看就知道 “今天你家只卖了 100 单”，商业机密就漏了；甚至有人会按顺序刷你家订单信息，不安全。

（四）生成 ID 的系统得靠谱：不能掉链子

比如大促的时候，每秒要生成上万订单 ID，要是 “发号器” 卡了、崩了，用户就下不了单 —— 所以这系统得 “稳”（全年 99.999% 时间能用）、“快”（眨眼间生成一堆 ID）。

三、常见的 4 种生成办法：优缺点一眼懂

市面上有 4 种主流办法，各有长短，咱们挑实用的讲：

（一）UUID：简单但 “不实用”

就是生成一个超长的字符串，比如550e8400-e29b-41d4-a716-446655440000，全世界唯一。

优点：本地就能生成，不用连数据库 / 服务器，快得很。缺点：

1. 太长了！存数据库占地方，查起来也慢；
2. 没规律（一会儿字母一会儿数字），数据库按这 ID 排序会很费劲；
3. 早期版本会暴露设备信息，不安全。总结：偶尔用用可以（比如生成临时文件名），订单、用户 ID 别用。

（二）雪花算法：分布式首选（但要注意 “时间”）

是 Twitter 开源的办法，把 ID 拆成 4 段，像拼积木一样：

• 第 1 段：不用（固定 0，保证 ID 是正数）；
• 第 2 段：时间（用毫秒算，能撑 69 年）；
• 第 3 段：机器号（区分哪台服务器生成的，比如 32 个机房、每个机房 32 台机器，都能区分）；
• 第 4 段：序列号（同一台机器同一毫秒最多生成 4096 个 ID，够快）。

优点：

1. ID 按时间涨，有规律；
2. 不依赖其他系统，自己服务器就能生成，稳又快；
3. 能自定义（比如多分配点位数给机器号，支持更多服务器）。缺点：怕 “时间回拨”—— 比如服务器时钟出问题，显示 “昨天”，就会生成和昨天重复的 ID。总结：大部分分布式场景（订单、用户 ID）都能用，只要把 “时间回拨” 问题解决好。

（三）数据库生成：老办法但 “不够快”

用数据库的 “自增 ID”，但加了点小技巧：比如弄 2 台数据库服务器，A 服务器从 1 开始、每次加 2（1、3、5、7…），B 服务器从 2 开始、每次加 2（2、4、6、8…），这样俩服务器不会重复。

优点：简单，不用额外开发，数据库自己就能搞；ID 是连续的，好存好查。缺点：

1. 慢！每次要 ID 都得连数据库，大促时数据库扛不住；
2. 扩展难：要是想加第 3 台服务器，得重新调规则，容易乱；
3. ID 太有规律，容易漏机密。总结：小系统能用，大系统别选。

（四）Redis 生成：快但 “怕丢数据”

Redis 有个incr命令，能让一个数字 “每次查都加 1”—— 比如初始是 1，查一次变 2，再查变 3，天生适合生成 ID。

优点：内存操作，比数据库快多了；能搞个 Redis 集群，稳得很。缺点：怕 Redis 崩了丢数据 —— 比如 Redis 记到 1000，一崩重启后又从 1 开始，就会重复。总结：要是能接受 “偶尔丢数据”（比如非核心业务 ID），可以用；核心业务（订单）慎选。

四、实战王者：美团 Leaf 方案（解决前面所有坑）

美团自己搞了个 “Leaf” 系统，把前面的办法优化了，专门应对大业务，分两种模式：

（一）Leaf-segment：数据库方案的 “升级版”

解决数据库 “慢” 的问题：不每次要 ID 都查数据库，而是 “批量拿号”。比如一次从数据库拿 1000 个号（1-1000），存在服务器内存里，发完了再去拿新的（1001-2000）。这样数据库压力小多了。

还加了 “双缓存”：比如当前在发 1-1000 的号，发完 100 个就偷偷去拿 1001-2000 的号存着，等 1-1000 发完，直接用新的，不用等数据库，更快。

优点：快、稳，能扛大流量；ID 是趋势递增的，好存。缺点：ID 还是有规律，怕漏机密（比如订单 ID 别用）。

（二）Leaf-snowflake：雪花算法的 “补坑版”

解决雪花算法 “时间回拨” 和 “机器号难分配” 的问题：

1. 机器号自动分配：用 Zookeeper（一个协调工具）给每台服务器分配唯一机器号，不用手动改配置；
2. 防时间回拨：启动时检查自己的时间和其他服务器是不是一致，差太多就报警；运行中要是时间往后跳，就暂时不发 ID，等时间追上再发。

优点：解决了雪花算法的坑，又保持了快、唯一的特点；ID 没规律，适合订单 ID。缺点：得搭 Zookeeper，稍微麻烦点。

五、怎么选？看业务场景

不用死记硬背，按下面的来：

1. 核心业务（订单、用户 ID）：选 Leaf-snowflake 或优化后的雪花算法（防时间回拨）；
2. 非核心业务（日志 ID、临时编号）：选 UUID 或 Redis；
3. 小系统、没技术资源：选 数据库生成（先凑合用，大了再换）；
4. 要 ID 有规律、又要扛流量：选 Leaf-segment（比如商品 ID，不用防机密）。

六、总结

分布式唯一 ID 的核心就是 “唯一、稳、快”，选方案不用追求 “最牛”，适合自己业务的才最好 —— 比如中小公司先用雪花算法，大公司再上 Leaf，一步步来就行。