其他分享
首页 > 其他分享> > 分布式ID 生成方案

分布式ID 生成方案

作者:互联网

分布式唯一 ID 生成方案浅谈 - 知乎 https://zhuanlan.zhihu.com/p/534893180

 

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

作者:shmilychen,腾讯 IEG 后开开发工程师

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

2.2. 数据库自增 ID

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

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

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

2.3. Redis 生成 ID

当使用数据库来生成 ID 性能不够的时候,可以尝试使用 Redis 来生成 ID。主要使用 Redis 的原子操作 INCR 和 INCRBY 来实现。优势是不依赖于数据库,使用灵活,性能也优于数据库;而缺点则是可能要引入新的组件 Redis,如果 Redis 出现单点故障问题,则会影响序号服务的可用性。

2.4. Zookeeper 生成 ID

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

2.5. Snowflake 算法

snowflake(雪花算法)是一个开源的分布式 ID 生成算法,结果是一个 long 型的 ID。snowflake 算法将 64bit 划分为多段,分开来标识机器、时间等信息,具体组成结构如下图所示:

snowflake 算法的核心思想是使用 41bit 作为毫秒数,10bit 作为机器的 ID(比如其中 5 个 bit 可作为数据中心,5 个 bit 作为机器 ID),12bit 作为毫秒内的流水号(意味着每个节点在每毫秒可以产生 4096 个 ID),最后还有一个符号位,永远是 0。

snowflake 算法可以根据自身业务的需求进行一定的调整。比如估算未来的数据中心个数,每个数据中心内的机器数,以及统一毫秒内的并发数来调整在算法中所需要的 bit 数。

snowflake 算法的优势是稳定性高,不依赖于数据库等第三方系统;使用灵活方便,可以根据业务需求的特性来调整算法中的 bit 位;单机上 ID 单调自增,毫秒数在高位,自增序列在低位,整个 ID 是趋势递增的。而其也存在一定的缺陷,包括强依赖机器时钟,如果机器上时钟回拨,会导致发号重复或者服务处于不可用状态;ID 可能不是全局递增,虽然 ID 在单机上是递增的,但是由于涉及到分布式环境下的每个机器节点上的时钟,可能会出现不是全局递增的场景。

3. 数据库号段模式

3.1. 号段模式介绍

号段模式是当下分布式 ID 生成器的主流实现方式之一,号段模式可以理解成从数据库批量获取 ID,然后将 ID 缓存在本地,以此来提高业务获取 ID 的效率。例如,每次从数据库获取 ID 时,获取一个号段,如(1,1000],这个范围表示 1000 个 ID,业务应用在请求获取 ID 时,只需要在本地从 1 开始自增并返回,而不用每次去请求数据库,一直到本地自增到 1000 时,才去数据库重新获取新的号段,后续流程循环往复。

3.2. 美团 Leaf-segment 方案

Leaf-segment 号段模式是对直接用数据库自增 ID 充当分布式 ID 的一种优化,减少对数据库的访问频率。相当于每次从数据库批量的获取自增 ID。

Leaf-server 采用了预分发的方式生成 ID,即可以在 DB 之上挂 N 个 Server,每个 Server 启动时,都会去 DB 拿固定长度的 ID List。这样就做到了完全基于分布式的架构,同时因为 ID 是由内存分发,所以也可以做到很高效。接下来是数据持久化问题,Leaf 每次去 DB 拿固定长度的 ID List,然后把最大的 ID 持久化下来,也就是并非每个 ID 都做持久化,仅仅持久化一批 ID 中最大的那一个。其流程如下图所示:

Leaf-server 中缓存的号段耗尽之后再去数据库获取新的号段,可以大大地减轻数据库的压力。对 max_id 字段做一次 update 操作,update max_id = max_id + step,update 成功则说明新号段获取成功,新的号段范围为(max_id, max_id + step]。

为了解决从数据库获取新的号段阻塞业务获取 ID 的流程的问题,Leaf-server 中采用了异步更新的策略,同时通过双 buffer 的方式,如下图所示。通过这样一种机制可以保证无论何时 DB 出现问题,都能有一个 buffer 的号段可以正常对外提供服务,只有 DB 在一个 buffer 的下发周期内恢复,都不会影响这个 Leaf 集群的可用性。

3.3. 滴滴 Tingid 方案

Tinyid 方案是在 Leaf-segment 的算法基础上升级而来,不仅支持了数据库多主节点模式,还提供了 tinyid-client 客户端的接入方式,使用起来更加方便。

Tinyid 会将可用号段加载到内存中,并在内存中生成 ID,可用号段在首次获取 ID 时加载,如当前号段使用达到一定比例时,系统会异步的去加载下一个可用号段,以此保证内存中始终有可用号段,以便在发号服务宕机后一段时间内还有可用 ID。实现原理如下所示:

3.4. 微信序列号生成方案

微信序列号跟用户 uin 绑定,具有以下性质:递增的 64 位整形;使用每个用户独立的 64 位 sequence 的体系,而不是用一个全局的 64 位(或更高位) sequence ,很大原因是全局唯一的 sequence 会有非常严重的申请互斥问题,不容易去实现一个高性能高可靠的架构。其实现方式包含如下两个关键点:

1)步进式持久化:增加一个缓存中间层,内存中缓存最近一个分配出现的 sequence:cur_seq,以及分配上限:max_seq;分配 sequence 时,将 cur_seq++,与分配上限 max_seq 比较,如果 cur_seq > max_seq,将分配上限提升一个步长 max_seq += step,并持久化 max_seq;重启时,读出持久化的 max_seq,赋值给 cur_seq。此种处理方式可以降低持久化的硬盘 IO 次数,可以系统的整体吞吐量。

2)分号段共享存储:引入号段 section 的概念,uin 相邻的一段用户属于一个号段,共享一个 max_seq。该处理方式可以大幅减少 max_seq 数据的大小,同时可以进一步地降低 IO 次数。

微信序列号服务的系统架构图如下图所示:

4. 雪花模式

4.1. 雪花模式介绍

雪花模式实现方式详见上面介绍的 snowflake 算法。

由于雪花算法强依赖于机器时间,如果时间上的时钟发生回拨,则可能引起生成的 id 冲突的问题。解决该问题的方案如下所示:

4.2. 美团 Leaf-snowflake 方案

Leaf-snowflake 方案沿用 snowflake 方案的 bit 位设计,即”1+41+10+12“的方式组装 ID 号(正数位(占 1 比特)+ 时间戳(占 41 比特)+ 机器 ID(占 5 比特)+ 机房 ID(占 5 比特)+ 自增值(占 12 比特)),如下图所示:

对于 workerID 的分配,当服务集群较小时,通过配置即可;当服务集群较大时,基于 zookeeper 持久顺序节点的特性引入 zookeeper 组件配置 workerID。部署架构如下图所示:

Leaf-snowflake 方案在处理时钟回拨问题的策略如下所示:

1)服务启动时

2)服务运行时

4.3. 百度 UidGenerator 方案

UidGenerator 方案是基于 snowflake 算法的唯一 ID 生成器。其对雪花算法的 bit 位的分配做了微调,如下图所示:

UidGenerator 方案包含以下两种实现方式:

1)DefaultUidGenerator 实现方式

DefaultUidGenerator 方式的实现要点如下所示:

DefaultUidGenerator 方式在出现任何刻度的时钟回拨时都会直接抛异常给到业务层,实现比较简单粗暴。故使用 DefaultUidGenerator 方式生成分布式 ID,需要根据业务情况和特点,调整各个字段占用的位数。

2)CachedUidGenerator 实现方式

CachedUidGenerator 的核心是利用 RingBuffer,本质上是一个数组,数组中每个项被称为 slot。CachedUidGenerator 设计了两个 RingBuffer,一个保存唯一 ID,一个保存 flag。其实现要点如下所示:

4.4. 基于多时间线改进的雪花算法

基于多时间线改进的雪花算法在 snowflake 基础上增加了时间线部分(1~2 位),可同时支持 2~4 条时间线并行。其对雪花算法的 bit 位的分配做了微调,如下图所示:

基于多时间线改进的雪花算法生成 ID 过程如下所示:

该方案虽然通过设置时间线方式有效解决了时钟回退问题,但是削弱了 snowflake 的趋势递增特性。比较适合对于一些频繁地、小步长的时钟回退情况,即能做到全局唯一,又能很好地兼顾递增趋势。

参考资源:

【1】https://tech.meituan.com/2019/03/07/open-source-project-leaf.html

【2】https://cloud.tencent.com/developer/article/1598569

【3】https://www.infoq.cn/article/wechat-serial-number-generator-architecture

【4】https://juejin.cn/post/6844903686271926279#heading-1

【5】https://tech.meituan.com/2017/04/21/mt-leaf.html

【6】https://cloud.tencent.com/developer/article/1680001

发布于 2022-07-05 09:15

 

 

搜索

复制

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

腾讯技术工程 腾讯技术工程 已认证帐号  

作者:shmilychen,腾讯 IEG 后开开发工程师

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

2.2. 数据库自增 ID

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

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

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

2.3. Redis 生成 ID

当使用数据库来生成 ID 性能不够的时候,可以尝试使用 Redis 来生成 ID。主要使用 Redis 的原子操作 INCR 和 INCRBY 来实现。优势是不依赖于数据库,使用灵活,性能也优于数据库;而缺点则是可能要引入新的组件 Redis,如果 Redis 出现单点故障问题,则会影响序号服务的可用性。

2.4. Zookeeper 生成 ID

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

2.5. Snowflake 算法

snowflake(雪花算法)是一个开源的分布式 ID 生成算法,结果是一个 long 型的 ID。snowflake 算法将 64bit 划分为多段,分开来标识机器、时间等信息,具体组成结构如下图所示:

snowflake 算法的核心思想是使用 41bit 作为毫秒数,10bit 作为机器的 ID(比如其中 5 个 bit 可作为数据中心,5 个 bit 作为机器 ID),12bit 作为毫秒内的流水号(意味着每个节点在每毫秒可以产生 4096 个 ID),最后还有一个符号位,永远是 0。

snowflake 算法可以根据自身业务的需求进行一定的调整。比如估算未来的数据中心个数,每个数据中心内的机器数,以及统一毫秒内的并发数来调整在算法中所需要的 bit 数。

snowflake 算法的优势是稳定性高,不依赖于数据库等第三方系统;使用灵活方便,可以根据业务需求的特性来调整算法中的 bit 位;单机上 ID 单调自增,毫秒数在高位,自增序列在低位,整个 ID 是趋势递增的。而其也存在一定的缺陷,包括强依赖机器时钟,如果机器上时钟回拨,会导致发号重复或者服务处于不可用状态;ID 可能不是全局递增,虽然 ID 在单机上是递增的,但是由于涉及到分布式环境下的每个机器节点上的时钟,可能会出现不是全局递增的场景。

3. 数据库号段模式

3.1. 号段模式介绍

号段模式是当下分布式 ID 生成器的主流实现方式之一,号段模式可以理解成从数据库批量获取 ID,然后将 ID 缓存在本地,以此来提高业务获取 ID 的效率。例如,每次从数据库获取 ID 时,获取一个号段,如(1,1000],这个范围表示 1000 个 ID,业务应用在请求获取 ID 时,只需要在本地从 1 开始自增并返回,而不用每次去请求数据库,一直到本地自增到 1000 时,才去数据库重新获取新的号段,后续流程循环往复。

3.2. 美团 Leaf-segment 方案

Leaf-segment 号段模式是对直接用数据库自增 ID 充当分布式 ID 的一种优化,减少对数据库的访问频率。相当于每次从数据库批量的获取自增 ID。

Leaf-server 采用了预分发的方式生成 ID,即可以在 DB 之上挂 N 个 Server,每个 Server 启动时,都会去 DB 拿固定长度的 ID List。这样就做到了完全基于分布式的架构,同时因为 ID 是由内存分发,所以也可以做到很高效。接下来是数据持久化问题,Leaf 每次去 DB 拿固定长度的 ID List,然后把最大的 ID 持久化下来,也就是并非每个 ID 都做持久化,仅仅持久化一批 ID 中最大的那一个。其流程如下图所示:

Leaf-server 中缓存的号段耗尽之后再去数据库获取新的号段,可以大大地减轻数据库的压力。对 max_id 字段做一次 update 操作,update max_id = max_id + step,update 成功则说明新号段获取成功,新的号段范围为(max_id, max_id + step]。

为了解决从数据库获取新的号段阻塞业务获取 ID 的流程的问题,Leaf-server 中采用了异步更新的策略,同时通过双 buffer 的方式,如下图所示。通过这样一种机制可以保证无论何时 DB 出现问题,都能有一个 buffer 的号段可以正常对外提供服务,只有 DB 在一个 buffer 的下发周期内恢复,都不会影响这个 Leaf 集群的可用性。

3.3. 滴滴 Tingid 方案

Tinyid 方案是在 Leaf-segment 的算法基础上升级而来,不仅支持了数据库多主节点模式,还提供了 tinyid-client 客户端的接入方式,使用起来更加方便。

Tinyid 会将可用号段加载到内存中,并在内存中生成 ID,可用号段在首次获取 ID 时加载,如当前号段使用达到一定比例时,系统会异步的去加载下一个可用号段,以此保证内存中始终有可用号段,以便在发号服务宕机后一段时间内还有可用 ID。实现原理如下所示:

3.4. 微信序列号生成方案

微信序列号跟用户 uin 绑定,具有以下性质:递增的 64 位整形;使用每个用户独立的 64 位 sequence 的体系,而不是用一个全局的 64 位(或更高位) sequence ,很大原因是全局唯一的 sequence 会有非常严重的申请互斥问题,不容易去实现一个高性能高可靠的架构。其实现方式包含如下两个关键点:

1)步进式持久化:增加一个缓存中间层,内存中缓存最近一个分配出现的 sequence:cur_seq,以及分配上限:max_seq;分配 sequence 时,将 cur_seq++,与分配上限 max_seq 比较,如果 cur_seq > max_seq,将分配上限提升一个步长 max_seq += step,并持久化 max_seq;重启时,读出持久化的 max_seq,赋值给 cur_seq。此种处理方式可以降低持久化的硬盘 IO 次数,可以系统的整体吞吐量。

2)分号段共享存储:引入号段 section 的概念,uin 相邻的一段用户属于一个号段,共享一个 max_seq。该处理方式可以大幅减少 max_seq 数据的大小,同时可以进一步地降低 IO 次数。

微信序列号服务的系统架构图如下图所示:

4. 雪花模式

4.1. 雪花模式介绍

雪花模式实现方式详见上面介绍的 snowflake 算法。

由于雪花算法强依赖于机器时间,如果时间上的时钟发生回拨,则可能引起生成的 id 冲突的问题。解决该问题的方案如下所示:

4.2. 美团 Leaf-snowflake 方案

Leaf-snowflake 方案沿用 snowflake 方案的 bit 位设计,即”1+41+10+12“的方式组装 ID 号(正数位(占 1 比特)+ 时间戳(占 41 比特)+ 机器 ID(占 5 比特)+ 机房 ID(占 5 比特)+ 自增值(占 12 比特)),如下图所示:

对于 workerID 的分配,当服务集群较小时,通过配置即可;当服务集群较大时,基于 zookeeper 持久顺序节点的特性引入 zookeeper 组件配置 workerID。部署架构如下图所示:

Leaf-snowflake 方案在处理时钟回拨问题的策略如下所示:

1)服务启动时

2)服务运行时

4.3. 百度 UidGenerator 方案

UidGenerator 方案是基于 snowflake 算法的唯一 ID 生成器。其对雪花算法的 bit 位的分配做了微调,如下图所示:

UidGenerator 方案包含以下两种实现方式:

1)DefaultUidGenerator 实现方式

DefaultUidGenerator 方式的实现要点如下所示:

DefaultUidGenerator 方式在出现任何刻度的时钟回拨时都会直接抛异常给到业务层,实现比较简单粗暴。故使用 DefaultUidGenerator 方式生成分布式 ID,需要根据业务情况和特点,调整各个字段占用的位数。

2)CachedUidGenerator 实现方式

CachedUidGenerator 的核心是利用 RingBuffer,本质上是一个数组,数组中每个项被称为 slot。CachedUidGenerator 设计了两个 RingBuffer,一个保存唯一 ID,一个保存 flag。其实现要点如下所示:

4.4. 基于多时间线改进的雪花算法

基于多时间线改进的雪花算法在 snowflake 基础上增加了时间线部分(1~2 位),可同时支持 2~4 条时间线并行。其对雪花算法的 bit 位的分配做了微调,如下图所示:

基于多时间线改进的雪花算法生成 ID 过程如下所示:

该方案虽然通过设置时间线方式有效解决了时钟回退问题,但是削弱了 snowflake 的趋势递增特性。比较适合对于一些频繁地、小步长的时钟回退情况,即能做到全局唯一,又能很好地兼顾递增趋势。

参考资源:

【1】https://tech.meituan.com/2019/03/07/open-source-project-leaf.html

【2】https://cloud.tencent.com/developer/article/1598569

【3】https://www.infoq.cn/article/wechat-serial-number-generator-architecture

【4】https://juejin.cn/post/6844903686271926279#heading-1

【5】https://tech.meituan.com/2017/04/21/mt-leaf.html

【6】https://cloud.tencent.com/developer/article/1680001

发布于 2022-07-05 09:15

标签:数据库,生成,回拨,号段,ID,分布式
来源: https://www.cnblogs.com/rsapaper/p/16453755.html