分布式唯一 ID生成方案

一、背景
二、分布式ID的几种生成方案
三、总结

一、背景

在构建一个高效、可靠的分布式系统时，唯一 ID 的生成成为了一项关键任务。这些 ID 不仅需唯一地标识每个数据实体，如用户、商品、订单，还必须满足高性能和高可用性的严苛要求。

一方面，传统的数据库自增主键在单体数据库中表现良好，但在面对大规模分布式系统、分库分表的场景时，它们显示出了局限性。在这种背景下，一个能够生成全局唯一 ID 的系统变得至关重要。该系统需满足以下几个关键要求：全局唯一性，以确保数据的准确识别；趋势递增，以保证数据的有序性和可追踪性；以及信息安全，防止恶意用户通过预测 ID 进行数据泄露或攻击。

另一方面，递增和趋势递增的 ID 提供了查询效率和数据整合的优势。递增 ID 简单直观，每个新生成的 ID 都比前一个大。趋势递增的 ID 则在一定时间内保持递增趋势，但不要求每个 ID 严格按顺序增加，从而提供更好的灵活性和安全性。这样的设计不仅加强了数据管理的效率，还有效避免了热点问题，提高了系统的整体性能。

为了应对分布式系统的挑战，我们需要一个既能够确保 ID 的全局唯一性、趋势递增，又能保证查询效率和系统安全性的高效 ID 生成策略。通过精心设计这样的系统，我们可以确保数据的完整性和一致性，同时保持系统的高效运行。

二、分布式ID的几种生成方案

2.1 UUID

UUID（Universally Unique Identifier）的标准型式包含 32 个 16 进制数字，以连字号分为五段，形式为 8-4-4-4-12 的 36 个字符，示例：550e8400-e29b-41d4-a716-446655440000

优点：

性能非常高：本地生成，没有网络消耗
因为是全球唯一的ID，所以迁移数据容易

缺点：

ID是无序的，无法保证趋势递增
相对于数字类型查询效率慢
不易于存储：UUID 太长，16 字节 128 位，通常以 36 长度的字符串表示，很多场景不适用
信息不安全：基于 MAC 地址生成 UUID 的算法可能会造成 MAC 地址泄露，这个漏洞曾被用于寻找梅丽莎病毒的制作者位置

2.2 单表主键生成

专门创建一张表，利用表主键自增（auto_increment）特性

优点：

数字化，id递增
查询效率高
存储空间小

缺点：

单点问题，如果数据库挂了，就生成不了ID了
数据库压力大，高并发抗不住

2.3 多表主键生成

针对上述的单点问题，我们利用多台机器并设置步长
在这里插入图片描述
优点：

解决了单点问题

缺点：

无法扩容；
数据库的压力大，数据库自身性能无法满足高并发

2.4 Redis

利用redis的incr原子性操作

优点：

有序递增，可读性强
性能还可以

缺点：

占用带宽，每次要向redis进行请求
强依赖redis，并存在重复的概率（即使 Redis 开启了持久化，不管是快照（snapshotting，RDB）、只追加文件（append-only file, AOF）还是 RDB 和 AOF 的混合持久化，一旦redis挂了会有数据丢失的可能）

2.5 雪花算法（snowflake）

这种方案大致来说是一种以划分命名空间（UUID 也算，由于比较常见，所以单独分析）来生成 ID 的一种算法，Snowflake 是 Twitter 开源的分布式 ID 生成算法。Snowflake 把 64-bit 分别划分成多段，分开来标示机器、时间等，比如在 snowflake 中的 64-bit 分别表示如下图所示：

在这里插入图片描述

第 0 位： 符号位（标识正负），始终为 0，没有用，不用管
第 1~41 位： 一共 41 位，用来表示时间戳，单位是毫秒，可以支撑 2 ^41毫秒（约 69 年）
第 42~52 位： 一共 10 位，一般来说，前 5 位表示机房 ID，后 5 位表示机器 ID（实际项目中可以根据实际情况调整），这样就可以区分不同集群/机房的节点，这样就可以表示 32 个 IDC，每个 IDC 下可以有 32 台机器
第 53~64 位： 一共 12 位，用来表示序列号。序列号为自增值，代表单台机器每毫秒能够产生的最大 ID 数(2^12 = 4096),也就是说单台机器每毫秒最多可以生成 4096 个唯一 ID

理论上 snowflake 方案的 QPS 约为 409.6w/s，这种分配方式可以保证在任何一个 IDC 的任何一台机器在任意毫秒内生成的 ID 都是不同的。

优点：

ID 是趋势递增
不依赖数据库等第三方系统，以服务的方式部署，稳定性更高，生成 ID 的性能也是非常高的
可以根据自身业务特性分配 bit 位，非常灵活

缺点：

强依赖机器时钟，如果机器上时钟回拨，会导致发号重复或者服务会处于不可用状态

2.6 Leaf-segment 数据库方案

在这里插入图片描述

Leaf-segment 方案，在使用数据库的方案上，做了如下改变：

1、原 MySQL 方案每次获取 ID 都得读写一次数据库，造成数据库压力大。改为批量获取，每次获取一个 segment(step 决定大小)号段的值。用完之后再去数据库获取新的号段，可以大大的减轻数据库的压力

2、各个业务不同的发号需求用 biz_tag 字段来区分，每个 biz_tag 的 ID 获取相互隔离，互不影响。如果以后有性能需求需要对数据库扩容，不需要上述描述的复杂的扩容操作，只需要对 biz_tag 分库分表就行

ID规则表设计如下：
在这里插入图片描述

重要字段说明：
biz_tag 用来区分业务
max_id 表示该 biz_tag 目前所被分配的 ID 号段的最大值
step 表示每次分配的号段长度

优点：

Leaf 服务可以很方便的线性扩展，性能完全能够支撑大多数业务场景
ID 号码是趋势递增的 8byte 的 64 位数字，满足上述数据库存储的主键要求
容灾性高：Leaf 服务内部有号段缓存，即使 DB 宕机，短时间内 Leaf 仍能正常对外提供服务
可以自定义 max_id 的大小，非常方便业务从原有的 ID 方式上迁移过来

缺点：

ID 号码不够随机，能够泄露发号数量的信息，不太安全
TP999 数据波动大，当号段使用完之后还是会在获取新号段时，更新数据库的 I/O 依然会存在着等待，TP999数据会出现偶尔的尖刺
DB 宕机会造成整个系统不可用

Leaf 高可用容灾
对于第三点“DB 可用性”问题，可以采用一主两从的方式，同时分机房部署，Master 和 Slave 之间采用半同步方式同步数据。某团内部使用了奇虎 360 的Atlas 数据库中间件（已开源，改名为 DBProxy）做主从切换。当然这种方案在一些情况会退化成异步模式，甚至在非常极端情况下仍然会造成数据不一致的情况，但是出现的概率非常小。如果要保证 100%的数据强一致，可以选择使用“类 Paxos算法”实现的强一致 MySQL 方案，如 MySQL 5.7 中的 MySQL Group Replication。但是运维成本和精力都会相应的增加，根据实际情况选型即可

2.7 Leaf-segment的双 buffer 优化

在这里插入图片描述

针对上述第二个缺点，Leaf-segment 做了一些优化，简单的说就是：

Leaf 取号段的时机是在号段消耗完的时候进行的，也就意味着号段临界点的 ID 下发时间取决于下一次从 DB 取回号段的时间，并且在这期间进来的请求也会因为 DB 号段没有取回来，导致线程阻塞。如果请求 DB 的网络和 DB 的性能稳定，这种情况对系统的影响是不大的，但是假如取 DB 的时候网络发生抖动，或者 DB 发生慢查询就会导致整个系统的响应时间变慢

为此，希望 DB 取号段的过程能够做到无阻塞，不需要在 DB 取号段的时候阻塞请求线程，即当号段消费到某个点时就异步的把下一个号段加载到内存中。而不需要等到号段用尽的时候才去更新号段。这样做就可以很大程度上的降低系统的 TP999 指标

采用双 buffer 的方式，Leaf 服务内部有两个号段缓存区 segment。当前号段已下发 10%时，如果下一个号段未更新，则另启一个更新线程去更新下一个号段。当前号段全部下发完后，如果下个号段准备好了则切换到下个号段为当前segment 接着下发，循环往复

通常推荐 segment 长度设置为服务高峰期发号 QPS 的 600 倍（10 分钟），这样即使 DB 宕机，Leaf 仍能持续发号 10-20 分钟不受影响。每次请求来临时都会判断下个号段的状态，从而更新此号段，所以偶尔的网络抖动不会影响下个号段的更新

2.8 Leaf-snowflake 方案

Leaf-segment 方案可以生成趋势递增的 ID，同时 ID 号是可计算的，不适用于订单 ID 生成场景，比如竞对在两天中午 12 点分别下单，通过订单 id 号相减就能大致计算出公司一天的订单量，这个是不能忍受的。面对这一问题，某团提供了 Leaf-snowflake 方案。

Leaf-snowflake方案完全沿用snowflake方案的bit位设计，即是“1+41+10+12”的方式组装 ID 号。对于第三位 workerID 的分配，当服务集群数量较小的情况下，完全可以手动配置，如果Leaf 服务规模较大，动手配置成本太高。所以使用 Zookeeper 持久顺序节点的特性自动对 snowflake 节点配置 wokerID

Leaf-snowflake 是按照下面几个步骤启动的：

1、启动 Leaf-snowflake 服务，连接 Zookeeper，在 leaf_forever 父节点下检查自己是否已经注册过（是否有该顺序子节点）。如果有注册过直接取回自己的 workerID（zk顺序节点生成的 int 类型 ID 号），启动服务。
2、如果没有注册过，就在该父节点下面创建一个持久顺序节点，创建成功后取回顺序号当做自己的 workerID 号，启动服务

三、总结

以上全面分析了多种主流的分布式唯一 ID 生成策略。每种方案都有其优缺点，并适合不同的使用场景。通过对比这些方案，可以根据自己的业务需求和系统特性，选择最合适的分布式唯一 ID 生成策略。