分布式系统唯一 ID 生成方案汇总

一、数据库自增长序列或字段

最常见的方式，利用数据库，全数据库唯一

1.1、优点

• 简单，代码方便，性能可以接受
• 数字 ID 天然排序，对分页或者需要排序的结果很有帮助

1.2、缺点

• 不同数据库语法和实现不同，数据库迁移的时候或多数据库版本支持的时候需要处理
• 在单个数据库或读写分离或一主多从的情况下，只有一个主库可以生成。有单点故障的风险
• 在性能达不到要求的情况下，比较难于扩展。（不适用于海量高并发）
• 如果遇见多个系统需要合并或者涉及到数据迁移会相当痛苦
• 分表分库的时候会有麻烦
• 并非一定连续，类似 MySQL，当生成新 ID 的事务回滚，那么后续的事务也不会再用这个 ID 了。这个在性能和连续性的折中。如果为了保证连续，必须要在事务结束后才能生成 ID，那性能就会出现问题
• 在分布式数据库中，如果采用了自增主键的话，有可能会带来尾部热点。分布式数据库常常使用range的分区方式，在大量新增记录的时候，IO会集中在一个分区上，造成热点数据

优化方案

针对主库单点，如果有多个 Master 库，则每个 Master 库设置的起始数字不一样，步长一样，可以是 Master 的个数。比如：Master1 生成的是 1、4、7、10，Master2 生成的是 2、5、8、11，Master3 生成的是 3、6、9、12。这样就可以有效生成集群中的唯一 ID，也可以大大降低 ID 生成数据库操作的负载

二、UUID

常见的方式。可以利用数据库也可以利用程序生成，一般来说全球唯一。UUID 是由 32 个的 16 进制数字组成，所以每个 UUID 的长度是 128 位（16^32 = 2^128）。UUID作为一种广泛使用标准，有多个实现版本，影响它的因素包括时间、网卡 MAC 地址、自定义 Namesapce 等等

2.1、优点

• 简单，代码方便
• 生成 ID 性能非常好，基本不会有性能问题
• 全球唯一，在遇见数据迁移，系统数据合并，或者数据库变更等情况下，可以从容应对

2.2、缺点

• 没有排序，无法保证趋势递增
• UUID 往往是使用字符串存储，查询的效率比较低
• 存储空间比较大，如果是海量数据库，就需要考虑存储量的问题
• 传输数据量大
• 不可读

2.3、优化方案

UUID 的变种：
1、为了解决UUID不可读，可以使用 UUID to Int64 的方法
2、为了解决 UUID 无序的问题，NHibernate 在其主键生成方式中提供了 Comb 算法（combined guid/timestamp）。保留 GUID 的 10 个字节，用另 6 个字节表示 GUID 生成的时间（DateTime）

三、Redis 生成 ID

当使用数据库来生成 ID 性能不够要求的时候，我们可以尝试使用 Redis 来生成 ID。这主要依赖于Redis 是单线程的，所以也可以用生成全局唯一的 ID。可以用 Redis 的原子操作 INCR 和 INCRBY 来实现

3.1、优点

• 不依赖于数据库，灵活方便，且性能优于数据库
• 数字 ID 天然排序，对分页或者需要排序的结果很有帮助

3.2、缺点

• 如果系统中没有 Redis，还需要引入新的组件，增加系统复杂度
• 需要编码和配置的工作量比较大

四、Twitter 的 snowflake 算法（雪花算法）

snowflake是 Twitter 开源的分布式 ID 生成算法，结果是一个 long 型的 ID。其核心思想是：使用 41bit 作为毫秒数，10bit 作为机器的 ID（5 个 bit 是数据中心，5 个 bit 的机器ID），12bit 作为毫秒内的流水号（意味着每个节点在每毫秒可以产生 4096 个 ID），最后还有一个符号位，永远是 0

4.1、优点

• 不依赖于数据库，灵活方便，且性能优于数据库
• ID 按照时间在单机上是递增的

4.2、缺点

• 在单机上是递增的，但是由于涉及到分布式环境，每台机器上的时钟不可能完全同步，在算法上要解决时间回拨的问题

五、利用 zookeeper 生成唯一 ID

zookeeper 主要通过其 znode 数据版本来生成序列号，可以生成 32 位和 64 位的数据版本号，客户端可以使用这个版本号来作为唯一的序列号。
很少会使用 zookeeper 来生成唯一 ID。主要是由于需要依赖 zookeeper，并且是多步调用 API，如果在竞争较大的情况下，需要考虑使用分布式锁。因此，性能在高并发的分布式环境下，也不甚理想。

六、MongoDB 的 ObjectId

MongoDB 的 ObjectId 和 snowflake 算法类似。它设计成轻量型的，不同的机器都能用全局唯一的同种方法方便地生成它。MongoDB 从一开始就设计用来作为分布式数据库，处理多个节点是一个核心要求。使其在分片环境中要容易生成得多。

七、TiDB 的主键

TiDB 默认是支持自增主键的，对未声明主键的表，会提供了一个隐式主键 _tidb_rowid，因为这个主键大体上是单调递增的，所以也会出现我们前面说的"尾部热点"问题。

TiDB 也提供了 UUID 函数，而且在 4.0 版本中还提供了另一种解决方案 AutoRandom。TiDB 模仿MySQL 的 AutoIncrement，提供了 AutoRandom 关键字用于生成一个随机 ID 填充指定列。