浅谈分布式唯一ID生成方案

1. 分布式唯一 ID 特性

在业务开发中，会存在大量的场景都需要唯一 ID 来进行标识。比如，用户需要唯一身份标识；商品需要唯一标识；消息需要唯一标识；事件需要唯一标识等等。尤其是在分布式场景下，业务会更加依赖唯一 ID。

分布式唯一 ID 的特性如下：

• 全局唯一：必须保证生成的 ID 是全局性唯一的，这是分布式 ID 的基本要求；
• 有序性：生成的 ID 需要按照某种规则有序，便于数据库的写入和排序操作；
• 可用性：需要保证高并发下的可用性。除了对 ID 号码自身的要求，业务还对 ID 生成系统的可用性要求极高；
• 自主性：分布式环境下不依赖中心认证即可自行生成 ID；
• 安全性：不暴露系统和业务的信息。在一些业务场景下，会需要 ID 无规则或者不规则。

2. 常用分布式唯一 ID 生成方案

2.1. UUID

UUID（Universally Unique Identifier，即通用唯一标识码）算法的目的是生成某种形式的全局唯一 ID 来标识系统中的任一元素，尤其是在分布式环境下，UUID 可以不依赖中心认证即可自动生成全局唯一 ID。

UUID 的标准形式为 32 个十六进制数组成的字符串，且分割为五个部分，例如：467e8542-2275-4163-95d6-7adc205580a9。

基于使用场景的不同，会存在以下几个不同版本的 UUID 以供使用，如下所示：

• 基于时间的 UUID：主要依赖当前的时间戳和机器 mac 地址。优势是能基本保证全球唯一性，缺点是由于使用了 mac 地址，会暴露 mac 地址和生成时间；
• 分布式安全的 UUID：将基于时间的 UUID 算法中的时间戳前四位替换为 POSIX 的 UID 或 GID。优势是能保证全球唯一性，缺点是很少使用，常用库基本没有实现；
• 基于随机数的 UUID：基于随机数或伪随机数生成。优势是实现简单，缺点是重复几率可计算；
• 基于名字空间的 UUID（MD5 版）：基于指定的名字空间/名字生成 MD5 散列值得到。优势是不同名字空间/名字下的 UUID 是唯一的，缺点是 MD5 碰撞问题，只用于向后兼容；
• 基于名字空间的 UUID（SHA1 版）：将基于名字空间的 UUID（MD5 版）中国的散列算法修改为 SHA1。优势是不同名字空间/名字下的 UUID 是唯一的，缺点是 SHA1 计算相对耗时。

UUID 的优势是性能非常高，由于是本地生成，没有网络消耗。而其也存在一些缺陷，包括不易于存储，UUID 太长，16 字节 128 位，通常以 36 长度的字符串表示；信息不安全，基于时间的 UUID 可能会造成机器的 mac 地址泄露；ID 作为 DB 主键时在特定的场景下会存在一些问题。

2.2. 数据库自增 ID

数据库自增 ID 是最常见的一种生成 ID 方式。利用数据库本身来进行设置，在全数据库内保持唯一。优势是使用简单，满足基本业务需求，天然有序；缺点是强依赖 DB，会由于数据库部署的一些特性而存在单点故障、数据一致性等问题。

针对上面介绍的数据库自增 ID 的缺陷，会存在以下两种优化方案：

• 数据库水平拆分，设置不同的初始值和相同的步长。这样可以有效的生成集群中的唯一 ID，也大大降低 ID 生成数据库操作的负载。
• 批量生成一批 ID。这样可以将数据库的压力减小到先前的 N 分之一，且数据库故障后仍可继续使用一段时间。此种方法详见下面的数据库号段模式介绍。

数据库自增 ID 方案的优势是非常简单，可利用现有数据库系统的功能实现；ID 号单调自增。其缺陷包括强依赖 DB，当 DB 异常时整个系统将处于不可用的状态；ID 号的生成速率取决于所使用数据库的读写性能。

2.3. Redis 生成 ID

当使用数据库来生成 ID 性能不够的时候，可以尝试使用 Redis 来生成 ID。主要使用 Redis 的原子操作 INCR 和 INCRBY 来实现。优势是不依赖于数据库，使用灵活&