分布式唯一ID的生成方案

分布式ID的特性

• 全局唯一

不能出现重复的ID，这是最基本的要求。

• 递增

有利于关系数据库索引性能。

• 高可用

既然是服务于分布式系统，为多个服务提供ID服务，访问压力一定很大，所以需要保证高可用。

• 信息安全

如果ID是有规律的，就容易被恶意操作，在一些场景下需要ID无规则。

生成方案

UUID

核心思想是结合机器的网卡、当地时间、一个随机数来生成。

优点：

• 性能非常高，本地生成，没有网络消耗。
• 生成简单，没有高可用风险。
• 有利于信息安全，因为可读性差，无规律。

缺点：

• 太长，不易于存储。
• 有利于信息安全的同时，也有不安全性，因为基于MAC地址生成的算法可能会泄露MAC地址。
• 无序，对MySQL索引不利，在 InnoDB 中，无序性会导致数据位置频繁变动，性能低下。

数据库

利用数据库自增ID的特性来生成，如 MySQL 的 auto_increment。

优点：

• 简单，利用数据库自有功能实现。
• 绝对有序。

缺点：

• 有重复发号的风险，例如数据库主从切换的场景。
• 需要特别保障其高可用。
• 发号性能限制于数据库性能，如需提高发号能力，需要扩充数据库，成本高。

Redis

Redis 提供了自增的原子命令，可以保证唯一、有序。

优点：

• 简单，自有能力。
• 高并发环境下性能好，优于数据库。
• 维护成本低于数据库。

缺点：

• 主从切换时也可能会重复发号。
• 需要特别保障其高可用。

雪花算法

给每台机器分配一个唯一标识，然后通过下面的结构实现全局唯一ID：

时间戳 + 机器标识 + 自增序列号

毫秒在高位，自增序列在低位，一定是递增的。

优点：

• 生成性能高。
• 灵活，可以根据自身业务特点分配bit位。

缺点：

• 强依赖机器时钟，如果时钟回拨，就会导致服务异常。

小结

不同的方案有不同的特点，需要根据自己的需求场景来选择适合的。

例如在美团早期，ID方案就是多种形式的：

• 有的业务通过 DB 自增的方式生成
• 有的业务通过 Redis 缓存来生成
• 有的业务直接用 UUID 生成

后来推出了一个类雪花算法的分布式ID服务：Leaf，QPS压测结果近5w/s。

项目地址：

https://github.com/Meituan-Dianping/Leaf

再推荐2个参考项目：

• 基于 Redis 的生成器

https://github.com/hengyunabc/redis-id-generator

• 百度基于雪花算法的生成器

https://github.com/baidu/uid-generator