开源分布式ID生成器UidGenerator的技术实现

时间 2020-03-23

原文原文链接

一、引言

不少人一想到IM应用开发，第一印象就是“长链接”、“socket”、“保活”、“协议”这些关键词，没错，这些确实是IM开发中确定会涉及的技术范畴。html

但，当你真正开始编写第一行代码时，最现实的问题其实是“聊天消息ID该怎么生成？”这个看似微不足道的小事情。说它看似微不足道，是由于在IM里它太日常了，到处可见它的身影。不过，虽然看似微不足道，但实际却很重要，由于它的生成算法和生成策略的优劣在某种意义上来讲，决定了你的IM应用层某些功能实现的难易度。node

有签于此，即时通信网专门整理了“IM消息ID技术专题”系列文章，但愿能带给你对这个看似微小但却很重要的技术点有更深入的理解和最佳实践思路。git

本文是专题系列文章的第5篇，专门介绍百度开源的分布式消息ID生成器UidGenerator的算法逻辑、实现思路、重点源码解读等，或许能带给你更多的启发。github

二、基本介绍

全局ID（常见的好比：IM聊天系统中的消息ID、电商系统中的订单号、外卖应用中的订单号等）服务是分布式服务中的基础服务，须要保持全局惟1、高效、高可靠性。有些时候还可能要求保持单调，但也并不是必定要严格递增或者递减。算法

全局ID也能够经过数据库的自增主键来获取，可是若是要求QPS很高显然是不现实的。sql

UidGenerator（备用地址）工程是百度开源的基于Snowflake算法的惟一ID生成器（百度对Snowflake算法进行了改进），引入了高性能队列高性能队列disruptor中RingBuffer思想，进一步提高了效率。docker

UidGenerator是Java语言实现的，它以组件形式工做在应用项目中，支持自定义workerId位数和初始化策略,，从而适用于docker等虚拟化环境下实例自动重启、漂移等场景。数据库

在技术实现上，UidGenerator有如下关键特性：编程

1）UidGenerator经过借用将来时间来解决sequence自然存在的并发限制；数组

2）采用RingBuffer来缓存已生成的UID, 并行化UID的生产和消费；

3）同时对CacheLine补齐，避免了由RingBuffer带来的硬件级「伪共享」问题。

基于以上技术特性，UidGenerator的单机压力测试数据显示，其QPS可高达600万。

依赖的环境：

1）Java8及以上版本（代码中使用了函数式编程语句等新特性，请见：uid-generator源码在线版）；

2）MySQL（内置WorkerID分配器, 启动阶段经过DB进行分配; 如自定义实现, 则DB非必选依赖）。

如下是UidGenerator工程的相关资源：

1）完整源码地址：https://github.com/baidu/uid-generator

2）备用源码地址：https://github.com/52im/uid-generator

3）源码在线阅读：http://docs.52im.net/extend/docs/src/uid-generator/（推荐）

三、什么是Snowflake算法？

3.1 SnowFlake算法原理

友情提示：本节文字内容摘选自《IM消息ID技术专题(四)：深度解密美团的分布式ID生成算法》一文，若是您想了解美团对于SnowFlake算法的理解和应用状况，可详细阅读之。

SnowFlake 算法，是 Twitter 开源的分布式 ID 生成算法。其核心思想就是：使用一个 64 bit 的 long 型的数字做为全局惟一 ID。

这 64 个 bit 中，其中 1 个 bit 是不用的，而后用其中的 41 bit 做为毫秒数，用 10 bit 做为工做机器 ID，12 bit 做为序列号。

SnowFlake的ID构成：

（本图引用自《IM消息ID技术专题(四)：深度解密美团的分布式ID生成算法》）

SnowFlake的ID样本：

（本图引用自《IM消息ID技术专题(四)：深度解密美团的分布式ID生成算法》）

给你们举个例子吧，如上图所示，好比下面那个 64 bit 的 long 型数字：

1）第一个部分，是 1 个 bit：0，这个是无心义的；

2）第二个部分，是 41 个 bit：表示的是时间戳；

3）第三个部分，是 5 个 bit：表示的是机房 ID，10001；

4）第四个部分，是 5 个 bit：表示的是机器 ID，1 1001；

5）第五个部分，是 12 个 bit：表示的序号，就是某个机房某台机器上这一毫秒内同时生成的 ID 的序号，0000 00000000。

① 1 bit：是不用的，为啥呢？

由于二进制里第一个 bit 为若是是 1，那么都是负数，可是咱们生成的 ID 都是正数，因此第一个 bit 统一都是 0。

② 41 bit：表示的是时间戳，单位是毫秒。

41 bit 能够表示的数字多达 2^41 - 1，也就是能够标识 2 ^ 41 - 1 个毫秒值，换算成年就是表示 69 年的时间。

③ 10 bit：记录工做机器 ID，表明的是这个服务最多能够部署在 2^10 台机器上，也就是 1024 台机器。

可是 10 bit 里 5 个 bit 表明机房 id，5 个 bit 表明机器 ID。意思就是最多表明 2 ^ 5 个机房（32 个机房），每一个机房里能够表明 2 ^ 5 个机器（32 台机器）。

④12 bit：这个是用来记录同一个毫秒内产生的不一样 ID。

12 bit 能够表明的最大正整数是 2 ^ 12 - 1 = 4096，也就是说能够用这个 12 bit 表明的数字来区分同一个毫秒内的 4096 个不一样的 ID。理论上snowflake方案的QPS约为409.6w/s，这种分配方式能够保证在任何一个IDC的任何一台机器在任意毫秒内生成的ID都是不一样的。

简单来讲，你的某个服务假设要生成一个全局惟一 ID，那么就能够发送一个请求给部署了 SnowFlake 算法的系统，由这个 SnowFlake 算法系统来生成惟一 ID。

1）这个 SnowFlake 算法系统首先确定是知道本身所在的机房和机器的，好比机房 ID = 17，机器 ID = 12；
2）接着 SnowFlake 算法系统接收到这个请求以后，首先就会用二进制位运算的方式生成一个 64 bit 的 long 型 ID，64 个 bit 中的第一个 bit 是无心义的；
3）接着 41 个 bit，就能够用当前时间戳（单位到毫秒），而后接着 5 个 bit 设置上这个机房 id，还有 5 个 bit 设置上机器 ID；
4）最后再判断一下，当前这台机房的这台机器上这一毫秒内，这是第几个请求，给此次生成 ID 的请求累加一个序号，做为最后的 12 个 bit。

最终一个 64 个 bit 的 ID 就出来了，相似于：

（本图引用自《IM消息ID技术专题(四)：深度解密美团的分布式ID生成算法》）

这个算法能够保证说，一个机房的一台机器上，在同一毫秒内，生成了一个惟一的 ID。可能一个毫秒内会生成多个 ID，可是有最后 12 个 bit 的序号来区分开来。

下面咱们简单看看这个 SnowFlake 算法的一个代码实现，这就是个示例，你们若是理解了这个意思以后，之后能够本身尝试改造这个算法。

总之就是用一个 64 bit 的数字中各个 bit 位来设置不一样的标志位，区分每个 ID。

3.2 SnowFlake算法的代码实现

SnowFlake 算法的一个典型Java实现代码，能够参见文章中的第“6.5 方案四：SnowFlake 算法的思想分析”节：《通俗易懂：如何设计能支撑百万并发的数据库架构？》，是Jack Jiang曾在某项目中实际使用过的代码。

3.3 SnowFlake算法的优缺点

对于份布式的业务系统来讲，SnowFlake算法的优缺点以下。

► 优势：

1）毫秒数在高位，自增序列在低位，整个ID都是趋势递增的；

2）不依赖数据库等第三方系统，以服务的方式部署，稳定性更高，生成ID的性能也是很是高的；

3）能够根据自身业务特性分配bit位，很是灵活。

► 缺点：

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

四、UidGenerator改进后的SnowFlake算法

经过上节，咱们知道了原版SnowFlake算法的基本构成。

具体是，原版SnowFlake算法核心组成：

原版SnowFlake算法各字段的具体意义是：

1）1位sign标识位；

2）41位时间戳；

3）10位workId（即5位数据中心id+5位工做机器id）；

4）12位自增序列。

而UidGenerator改进后的SnowFlake算法核心组成以下图：

简单来讲，UidGenerator能保证“指定机器 & 同一时刻 & 某一并发序列”，是惟一，并据今生成一个64 bits的惟一ID（long），且默认采用上图字节分配方式。

与原版的snowflake算法不一样，UidGenerator还支持自定义时间戳、工做机器id和序列号等各部分的位数，以应用于不一样场景（详见源码实现）。

如上图所示，UidGenerator默认ID中各数据位的含义以下：

1）sign(1bit)：固定1bit符号标识，即生成的UID为正数。
2）delta seconds (28 bits)：当前时间，相对于时间基点"2016-05-20"的增量值，单位：秒，最多可支持约8.7年（注意：(a)这里的单位是秒，而不是毫秒！ (b)注意这里的用词，是“最多”可支持8.7年，为何是“最多”，后面会讲）。
3）worker id (22 bits)：机器id，最多可支持约420w次机器启动。内置实现为在启动时由数据库分配，默认分配策略为用后即弃，后续可提供复用策略。
4）sequence (13 bits)：每秒下的并发序列，13 bits可支持每秒8192个并发（注意下这个地方，默认支持qps最大为8192个）。

五、UidGenerator的具体代码实现分析

经过阅读UidGenerator的源码可知，UidGenerator的具体实现有两种选择，即 DefaultUidGenerator 和 CachedUidGenerator。咱们分别来看看这两个具体代码实现的精妙之处。

5.1 DefaultUidGenerator

DefaultUidGenerator 的源码很清楚的说明了几个生成ID的关键位的实现逻辑。

1）delta seconds（28 bits）：

这个值是指当前时间与epoch时间的时间差，且单位为秒。epoch时间就是指集成DefaultUidGenerator生成分布式ID服务第一次上线的时间，可配置，也必定要根据你的上线时间进行配置，由于默认的epoch时间但是2016-09-20，不配置的话，会浪费好几年的可用时间。

2）worker id（22bits）：

接下来讲一下DefaultUidGenerator是如何给worker id赋值的，搭建DefaultUidGenerator的话，须要建立一个表：

DROP DATABASE IF EXISTS `xxxx`;
CREATE DATABASE `xxxx` ;
use `xxxx`;
DROP TABLE IF EXISTS WORKER_NODE;
CREATE TABLE WORKER_NODE
(
    ID BIGINT NOT NULL AUTO_INCREMENT COMMENT 'auto increment id',
    HOST_NAME VARCHAR(64) NOT NULL COMMENT 'host name',
    PORT VARCHAR(64) NOT NULL COMMENT 'port',
    TYPE INT NOT NULL COMMENT 'node type: ACTUAL or CONTAINER',
    LAUNCH_DATE DATE NOT NULL COMMENT 'launch date',
    MODIFIED TIMESTAMP NOT NULL COMMENT 'modified time',
    CREATED TIMESTAMP NOT NULL COMMENT 'created time',
    PRIMARY KEY(ID)
)
COMMENT='DB WorkerID Assigner for UID Generator', ENGINE = INNODB;

DefaultUidGenerator会在集成用它生成分布式ID的实例启动的时候，往这个表中插入一行数据，获得的id值就是准备赋给workerId的值。因为workerId默认22位，那么，集成DefaultUidGenerator生成分布式ID的全部实例重启次数是不容许超过4194303次（即2^22-1），不然会抛出异常。

3）sequence（13bits）：

核心代码以下，几个实现的关键点：

a. synchronized保证线程安全；

b. 若是时间有任何的回拨，那么直接抛出异常；

c. 若是当前时间和上一次是同一秒时间，那么sequence自增。若是同一秒内自增值超过2^13-1，那么就会自旋等待下一秒（getNextSecond）；

d. 若是是新的一秒，那么sequence从新从0开始。

（上述源码节选自：DefaultUidGenerator 类中的 nextId() 方法）

4）小结：

经过DefaultUidGenerator的实现可知，它对时钟回拨的处理比较简单粗暴。另外若是使用UidGenerator的DefaultUidGenerator方式生成分布式ID，必定要根据你的业务的状况和特色，调整各个字段占用的位数：

<!-- Specified bits & epoch as your demand. No specified the default value will be used -->

    <property name="timeBits" value="29"/>

    <property name="workerBits" value="21"/>

    <property name="seqBits" value="13"/>

    <property name="epochStr" value="2016-09-20"/>

5.2 CachedUidGenerator

CachedUidGenerator是DefaultUidGenerator的重要改进实现。它的核心利用了RingBuffer，它本质上是一个数组，数组中每一个项被称为slot。CachedUidGenerator设计了两个RingBuffer，一个保存惟一ID，一个保存flag。RingBuffer的尺寸是2^n，n必须是正整数。

如下是CachedUidGenerator中的RingBuffer原理示意图：

扩展知识：什么是RingBuffer？

Ring Buffer的概念，其实来自于Linux内核（Maybe），是为解决某些特殊状况下的竞争问题提供了一种免锁的方法。这种特殊的状况就是当生产者和消费者都只有一个，而在其它状况下使用它也是必需要加锁的。

环形缓冲区一般有一个读指针和一个写指针。读指针指向环形缓冲区中可读的数据，写指针指向环形缓冲区中可写的缓冲区。经过移动读指针和写指针就能够实现缓冲区的数据读取和写入。在一般状况下，环形缓冲区的读用户仅仅会影响读指针，而写用户仅仅会影响写指针。若是仅仅有一个读用户和一个写用户，那么不须要添加互斥保护机制就能够保证数据的正确性。若是有多个读写用户访问环形缓冲区，那么必须添加互斥保护机制来确保多个用户互斥访问环形缓冲区。

更多具体的 CachedUidGenerator 的代码实现，有兴趣能够仔细读一读，也能够前往百度uid-generator工程的说明页看看具体的算法原理，这里就再也不赘述。

简要的小结一下，CachedUidGenerator方式主要经过采起以下一些措施和方案规避了时钟回拨问题和加强惟一性：

1）自增列：CachedUidGenerator的workerId在实例每次重启时初始化，且就是数据库的自增ID，从而完美的实现每一个实例获取到的workerId不会有任何冲突；
2）RingBuffer：CachedUidGenerator再也不在每次取ID时都实时计算分布式ID，而是利用RingBuffer数据结构预先生成若干个分布式ID并保存；
3）时间递增：传统的SnowFlake算法实现都是经过System.currentTimeMillis()来获取时间并与上一次时间进行比较，这样的实现严重依赖服务器的时间。而CachedUidGenerator的时间类型是AtomicLong，且经过incrementAndGet()方法获取下一次的时间，从而脱离了对服务器时间的依赖，也就不会有时钟回拨的问题（这种作法也有一个小问题，即分布式ID中的时间信息可能并非这个ID真正产生的时间点，例如：获取的某分布式ID的值为3200169789968523265，它的反解析结果为{"timestamp":"2019-05-02 23:26:39","workerId":"21","sequence":"1"}，可是这个ID可能并非在"2019-05-02 23:26:39"这个时间产生的）。

5.3 小结一下

CachedUidGenerator经过缓存的方式预先生成一批惟一ID列表，能够解决惟一ID获取时候的耗时。但这种方式也有很差点，一方面须要耗费内存来缓存这部分数据，另外若是访问量不大的状况下，提早生成的UID中的时间戳多是很早以前的。而对于大部分的场景来讲，DefaultUidGenerator 就能够知足相关的需求了，不必来凑CachedUidGenerator这个热闹。

另外，关于UidGenerator比特位分配的建议：

对于并发数要求不高、指望长期使用的应用, 可增长timeBits位数, 减小seqBits位数. 例如节点采起用完即弃的WorkerIdAssigner策略, 重启频率为12次/天, 那么配置成{"workerBits":23,"timeBits":31,"seqBits":9}时, 可支持28个节点以总体并发量14400 UID/s的速度持续运行68年.

对于节点重启频率频繁、指望长期使用的应用, 可增长workerBits和timeBits位数, 减小seqBits位数. 例如节点采起用完即弃的WorkerIdAssigner策略, 重启频率为24*12次/天, 那么配置成{"workerBits":27,"timeBits":30,"seqBits":6}时, 可支持37个节点以总体并发量2400 UID/s的速度持续运行34年.

六、UidGenerator的吞吐量压力测试

UidGenerator的测试数据显示，在MacBook Pro（2.7GHz Intel Core i5, 8G DDR3）上进行的CachedUidGenerator（单实例）的UID吞吐量测试状况以下。

首先：固定住workerBits为任选一个值(如20), 分别统计timeBits变化时(如从25至32, 总时长分别对应1年和136年)的吞吐量, 测试结果以下图所示：

再固定住timeBits为任选一个值(如31), 分别统计workerBits变化时(如从20至29, 总重启次数分别对应1百万和500百万)的吞吐量, 测试结果以下图所示：

因而可知：无论如何配置, CachedUidGenerator总能提供600万/s的稳定吞吐量，只是使用年限会有所减小，这真的是太棒了！

最后：固定住workerBits和timeBits位数(如23和31), 分别统计不一样数目(如1至8,本机CPU核数为4)的UID使用者状况下的吞吐量，测试结果以下图所示：

（本文同步发布于： http://www.52im.net/thread-2953-1-1.html）

七、参考资料

[1] 改进版Snowflake全局ID生成器-uid-generator

[2] UidGenerator

[3] 百度开源分布式id生成器uid-generator源码剖