CN106572165A - 一种分布式全局唯一id应用方法 - Google Patents

Abstract

本发明提供一种分布式全局唯一ID应用方法，包括以下两种类型：字符串类型的全局唯一ID，能够在没有网络情况下本地高效生成时间友好的全局唯一ID；数值型全局唯一ID，需要有网络通讯这一前提，从远程服务器获取数值型、时间友好的全局唯一ID；生成数值型全局唯一ID时，整个服务分为服务端生成ID机器集群和客户端，所述服务端生成唯一ID的机器，首先需要根据机器mac地址去MySQL数据库集群进行注册，获取服务机器唯一编号，保证服务端各个机器生成ID唯一；客户端通过增加缓存使得用户请求无感知。客户端和服务器通过HTTP请求进行数据交互。本发明实现了在不同ID类型需求场景下，高效的产生全局唯一ID的一套方案。

Description

一种分布式全局唯一ID应用方法

技术领域

本发明涉及一种分布式系统中全局唯一ID服务，特别是涉及需要一种能够高效地产生全局唯一ID的布式系统

背景技术

在分布式系统中，经常需要使用全局唯一ID(GUID)定义对应的数据。GUID的基本需求包括以下几点：1、全局唯一；2、占用相对较少,方便DB存储和索引；3、时间友好,方便业务查询；4、性能高,可用性高。当前现有解决方案都存在各自的问题,没有一种比较全面的方案。

关于SnowFlake，因本发明的实现基于Twitter公司的Snowflake方案,故先介绍一下snowflake，为了满足Twitter每秒上万条消息的请求，每条消息都必须分配一条唯一的ID，这些ID还需要一些大致的顺序(方便客户端排序)，并且在分布式系统中不同机器产生的ID必须不同,Twitter研发了snowflake生成ID方案.其核心思想是：产生一个long型的ID，使用其中41位(bit)作为时间戳(单位：毫秒)，10bit作为机器编号，12bit作为序列号。如图1所示：除了最高位(bit)标记为不可用以外，其余三组bit占位均可浮动，应具体的业务需求而定。默认情况下41bit的时间戳可以支持该算法使用69.7年，10bit的工作机器id可以支持1024台机器，序列号支持1毫秒产生4096个自增序列id。下面详细介绍一下各个段作用。

SnowFlake—时间戳

时间戳(time)—41bit，这里时间戳的细度是毫秒级，默认情况下有41个bit可以供使用，那么一共有T(1<<41)毫秒可以使用分配，年份＝T/(3600*24*365*1000)＝69.7年。也就是说snowflake能够保证69.7年不会产生相同的ID。同理,如果只给时间戳分配39个bit使用，那么根据同样的算法最后年份＝17.4年。

SnowFlake—工作机器ID

工作机器ID(machine id)—10bits，该部分其实由数据中心ID(datacenterId)和工作ID(workerId)两部分组成，来唯一标示一台生成snowflake的机器。Twitter这块通过zookeeper来保证序列的唯一。我们方案中把这部分作为一个整体来看待。

SnowFlake—序列号

序列号就是一系列的自增id(多线程建议使用atomic)，为了处理在同一毫秒内需要给多条消息分配id，若同一毫秒把序列号用完了，则“等待至下一毫秒”。sequence id—12bits，该id可以表示4096个数字，它是在time相同的情况下，递增该值直到为0，即一个循环结束，此时便只能等到下一个ms到来，一般情况下4096/ms的请求是不太可能出现的，所以足够使用了。

发明内容

本发明提供了一种分布式全局唯一ID应用方法，是在现有SnowFlake技术基础上，改进并实现的一种不需要联网、高效的本地生成字符串型全局唯一ID的方案。同时也提供了远程数值型全局唯一ID生成方案，作为字符串型全局唯一ID生成方案的有力补充。

现在需要考虑的是如何生成本地ID和远程获取ID的问题：

本地生成字符串类型全局唯一ID方案最需要解决的问题是如何保证服务器之间在不进行通讯的前提下，生成互不相同的ID。

远程获取数值型全局唯一ID方案中，现行SnowFlake方案需要引入分布式协调服务Zookeeper(分布式协调服务)来控制每台工作机器都被分配唯一的工作编号(work ID)，确保不同机器上通过相同逻辑生成唯一编号不冲突。但zookeeper服务相对而言比较重，需要一种更轻量的方式来高效的分配唯一编号，所以我们需要解决如何在没有zookeeper集群前提下,高效给服务器分配唯一工作编号(workID)的问题。

远程获取数值型全局唯一ID方案中，因每次请求都需要一次网络请求开销。对于用户响应要求高，或者全局唯一ID需求密集的场景下，这个开销时不能容忍的。所以需要解决如何在尽量用户无感知情况下获取远程服务器产生的全局唯一ID的问题。

针对以上产生的问题，本发明提出了相应的解决方案。

本地生成字符串类型全局唯一ID方案：

现有snowflake方案，有对网络和远程服务都是强依赖的致命缺点。为了解决这个问题，我们推出的本地生成字符串类型全局唯一ID方案，可以不依赖网络，完全在本地生成全局唯一ID，生成的ID是字符串类型的。

远程获取数值型全局唯一ID方案：

因字符串型全局唯一ID方案只能生成字符串类型ID，对于现有遗留数值型ID系统或者确实需要数值型全局唯一ID的场景无能为力。所以我们提供了远程HTTP访问获取数值型全局唯一ID的方案。

其技术方案如下所述：

一种分布式全局唯一ID应用方法，包括以下两种类型：字符串类型的全局唯一ID，能够在没有网络情况下本地高效生成时间友好全局唯一ID，所述生成时间友好是指生成时间晚的ID要大于生成时间早的ID，便于按照时间范围查找；数值型全局唯一ID，需要有网络通讯这一前提，从远程服务器获取数值型、时间友好的全局唯一ID；生成数值型全局唯一ID时，整个服务分为服务端生成ID机器集群和客户端。服务端生成唯一ID的机器，首先需要根据机器mac地址去MySQL数据库集群进行注册，获取服务机器唯一编号，保证服务端各个机器生成ID唯一，使其和其他机器不冲突。客户端通过增加缓存使得用户请求无感知，客户端和服务器通过HTTP请求进行数据交互。

本地生成的字符串类型全局唯一ID，由110位数据组成，包括最高48 位的时间位、中间48位的机器唯一标示位、最低14位的序列号位，并通过32进制编码将数据压缩成一个22字符长度的字符串,实现在无网络环境下生成短小无特殊字符全局唯一ID。

远程获取的数值型全局唯一ID通过MySQL数据库的自增主键和唯一主键进行处理，服务启动时,本方法根据机器mac地址去MySQL数据库集群进行注册，如果此mac地址已经注册过，则直接返回该机器已经注册过得编号；如果发现没有注册过，则插入一条记录，并返回id作为编号，从而使每台电脑都能得到一个唯一的编号。

远程获取的数值型全局唯一ID使用户请求无感知，通过在客户端增加缓存,每次请求都从服务器端批量获取数据，做到在现多线程情况下远程调用无感知的获取全局唯一ID。

所述客户端设有一个缓存队列，并单独使用一个worker线程请求服务端获取全局ID，消费线程每消费一个,worker线程就会往缓存队列里面放一个；当worker线程出现网络异常时,会首先进行重试,多次尝试依然失败后,会往缓存队列里面存放特殊岗哨对象，用于代表出现问题的标示,当消费线程发现获取的是特殊岗哨对象时,则说明work线程出现异常,然后通知上层调用者。

所述缓存的大小能够进行调整,最小能够调整为0,代表不使用缓存。

远程获取的数值型全局唯一ID中，共41位，第一位保持代表正数的0，依次包括41位时间戳、10位workID、12位序列号位。

所述序列号为初始随机、顺序递增形式，当服务器出现时间回退时,生成序列号时间不会回退，会继续使用上一次使用最晚时间；当一毫秒以内序列号大于最大标示4096以后，会使用下一毫秒的序列号,毫秒数会加一，序列号继续从0开始。

在连不到网络的测试环境中或者为了兼容以前数值类型的ID，还能够采用远程HTTP请求方式获取唯一ID，远程HTTP请求方式获取的唯一ID使用long类型的64bit，第一位保持0，后面依次由30bit时间段、13bit 的伪进程标识段、20bit的自增sequence段组成。

通过改进,实现了可以在没有网络的前提下,在本地高效生成时间友好的较短字符串型全局唯一ID方案。

同时，我们推出的远程http访问型解决方案，做到了在没有zookeeper集群前提下,实现了远程、灵活、消费者对远程无感知的全局唯一ID的生成.作为字符串型方案的有力补充，以适应需要数值型全局唯一ID的场景。

附图说明

图1是所述snowflake生成ID的方案表示；

图2是本发明中本地生成字符串类型全局唯一ID的方案表示；

图3是全局唯一ID服务器唯一编号获取流程图；

图4是GUID客户端缓存原理图；

图5是普通高可用部署架构示意图。

具体实施方式

本发明中，本地生成字符串类型全局唯一ID方案如下所述：

为了在服务器之间在不进行通讯的前提下的情况下,在本地还能生成全局唯一ID，在snowflake方案基础上,我们将机器的网卡地址编码到生成的ID里面，保证不通机器采用相同逻辑产生ID不会冲突。同时我们增大时间字段和机器标识字段的长度，这样可以标示更多的时间和单位时间内可用的序列号个数。如下图2所示,一共由110位(bit)数据组成。各个字段意义如下：

时间段

前48bit，记录从1970年1月1日00:00:00时间流逝数,单位毫秒。48bit能够记录8900多年，也就是能够标示到公元10000年以后。

mac地址段

存放48bit mac地址，每台机器都唯一。对一台机器需要部署多个全局ID服务的情况，可以将这个字段进行随机处理。因长度有48位，冲突概率可以忽略。

自增sequence段

长度为14个bit，理论上每毫秒最多可以产生16384个sequence，每秒1600万。

这样产生的本地生成字符串类型全局唯一ID因长度过长,不可能将这些数据放到一个长整形数据类型来表示。所以最终通过32进制编码将数据压缩成一个22字符长度的字符串，实现在无网络环境下生成短小无特殊字符全局唯一ID。

远程获取数值型全局唯一ID方案机器编号的确认方法主要通过MySQL数据库的自增主键和唯一主键来解决。

如图3,服务启动时,会根据机器mac地址(网卡硬件唯一标示,全球唯一),去MySQL数据库集群进行注册。如果此mac地址已经注册过，则直接返回该机器已经注册过得编号。如果发现没有注册过，则插入一条记录，并返回id作为编号。从而使每台电脑都能得到一个唯一的编号,这样就在不使用zookeeper的前提下,解决唯一ID产生机器编号问题。注意，此方案一台机器只能部署一个全局唯一ID服务。

表结构描述如下,其中：id为自增主键，mac_addr有唯一键约束。

全局唯一ID服务器唯一编号记录表结构展示如下：

进一步的，远程获取数值型全局唯一ID用户请求无感知解决方法如下所述：

通过在客户端增加缓存,每次请求都从服务器端批量获取数据,可以做到在现多线程情况下远程调用无感知的获取全局唯一ID。

实现原理图如下：左侧是多个GUID请求线程(Multi access)，中间是GUID客户端(GUID client),右边是远程生成GUID的服务端(远程GUID服务)。其中GUID就是前面讲过的全局唯一ID，GUID请求线程就是需要获得并使用GUID的线程。

中间矩形区域表示缓存队列，椭圆部分代表获取远程服务工作线程。为了做到客户端无感知,客户端设有一个缓存队列(ConcurrentLinkedQueue Buffer),并单独使用一个线程(worker线程)请求服务端获取全局ID。worker线程(Worker daemon)采用批量获取(http request/Batch request)的形式，并尝试放入(Put Block)阻塞的多线程队列，直到队列满，则worker线程阻塞。请求全局ID线程从阻塞队消费已经获取好的全局ID，做到对网络请求无感知。消费线程每消费一个，worker线程就会往缓存队列里面放一个。缓存队列里面始终保持着满或者接近满的状态。直到worker线程获取的当前批次数据全部放完，会再次去获取下一个批次的数据。

也就是说，作线程会一直尝试往队列放数据。消费者每消费一个，工作线程就会往里新放一个。批量获取大小确定需要考虑消费者性质。前面讲过,如果缓存变大,则工作线程获取新批次数据时,缓存中数据被取光的可能性更小,但获得GUID时间和生成GUID时间相差会很大。

当worker线程出现网络等异常时,会首先进行重试,多次尝试依然失败后，会往缓存队列里面存放特殊岗哨对象(一个代表出现问题的标示,看到这个标示证明系统出现问题了)；消费线程当发现获取的是特殊岗哨对象时,发现work线程出现异常,会通知上层调用者。

缓存大小是可调的,最小可以调整为0，代表不使用缓存，以适应不同的业务场景。

如果客户端关闭下线，缓存中GUID会被抛弃。下次启动后会从服务端重新获取新的GUID。

那么，可以看到，本地生成字符串类型全局唯一ID方案和远程获取数值型全局唯一ID方案对比：

优点：

本地生成,不需要引入远程服务依赖。大大减小系统复杂度。因生成只和本机Mac地址有关，天然分布式友好。

本地生成效率高，压测发现每秒钟能达到千万以上级别。

缺点：

为了达到全局唯一的标准，需要更多的数据位来保证全局唯一，所以ID数据占用空间会超过数值类型能标示的范围，只能用字符串类型来标示。

并且字符串类型会和原有数值类型ID不兼容。

因此本发明根据实际业务需求,做了3种改进实现方式：

1、本地生成字符串型GUID；

2、远程http请求获取型GUID；

3、本地生成型“伪”GUID。

首先是本地生成字符串型GUID介绍，适用场景在于：

需要获得字符串型全局唯一ID得地方就可以用。字符串型GUID方案具有天生的分布式特征，时间友好。和需要联网获取ID得方案相比，性能更高，系统复杂度降低，稳定性更好。

组成设计：

如“字符串型GUID组成图”所示.类似snowflake，将时间、机器码和Sequence(序列号)依次编码，最终通过Base32编码，生成长度为22个字符，时间友好的全局唯一ID。

一共由110bit组成，依次是48bit时间段、48bit mac地址段和14bit自增sequence段组成。最终按照32进制编码成一个长度为22的字符串。

优化改进在于：

采用32进制进行编码，即能缩小最终生成ID的长度，易于索引，又能防止64进制锁产生ID中存在特殊字符的问题。并且32进制编码实现是通过位运算实现，大大提升了运算效率。

每个段的长度都精心设计,时间段可以标示到公园10000年以后，不用担心重复问题,自增sequence每秒能产生1600万唯一ID。

生成完全本地化,无需联网即可生成唯一ID。天生分布式友好，大大减少了系统复杂度。

基于远程http请求GUID介绍如下所述，适用场景在于严格需要需要long类型全局唯一ID系统。

组成设计：

沿用了snowflake方案，long类型第一位保持0(正数)，依次是41bit时间戳，10bitworkID，12bit序列号位。参考时间从2016.7.613:30开始,可以使用69.7年。workID最多支持1024台机器，序列号每毫秒可以有4096个,每秒能达到400万。

优化改进：

序列号是初始随机,顺序递增的。防止序列号每次都0开始而影响hash分配等问题,序列号是初始随机,顺序递增的。当服务器出现时间回退时,生成序列号时间不会回退,会继续使用上一次使用最晚时间。当一毫秒以内序列号大于最大标示4096以后,会使用下一毫秒的序列号,毫秒数会加一，序列号继续从0开始，这样同时解决了服务时间回退以后，snowflake获取全局ID需要的时间等待问题。

之所以是初始随机、顺序递增，是因为每一毫秒可以生成4096个不同的ID。如果每次都从0开始，有可能这一毫秒只有5个请求，所以生成ID尾数为0～4。下一秒只有6个请求，则生成ID尾数为0～5。这样会发现尾数0出现的频率最高。后面数出现频率会降低。所以我们在初始的时候，会随机一个数，然后一直往上加(即使毫秒数变了也往上加)。当加到4095时，让毫秒数加一，让序列号重新归0。再像前面一样往上加。这样尾数就会分散，尾数分散在数据库分库等其他操作中有重要作用。

采用MySql存储mac ID和分配给机器的work ID对应关系，使部署简化，每个ID都能追踪到具体生成的机器。

编写了用户友好的客户端，客户端采用缓存方式，尽量做到对用户使用无感知。缓存大小可以设置为0,做到无缓存工作。

部署结构在于：

如图5所示，普通高可用部署架构即可满足http请求获取型GUID部署要求。最底层的MySQL集群,用于实现控制每台工作机器分配唯一的序列号,系统对MySQL集群压力很小,只需要保证不出现单点故障即可。MySQL集群上面是产生唯一ID服务器集群(Server1～N)，可以方便的动态扩展。服务器集群通过反向代理服务器(LVS/NGINX)进行负载均衡,并且提供给客户端(Clinet1～N)。

服务端提供服务的机器是对等的，如果一台机器下线,新的请求会由其它机器来提供服务。同样服务器端程序升级也是分批次堆机器进行升级,做到不停服平滑升级。

最后是本地生成“伪”GUID介绍，适用场景是在使用http请求数值类型全局唯一ID连不到网络的测试环境中,对于唯一性要求不是特别严格,可以使用此类ID。作为基于远程http请求GUID的有效补充。

组成设计：

使用long类型的64bit,第一位保持0，后面依次由30bit时间段、13bit的伪进程标识段、20bit的自增sequence段组成。

优化改进：

优化各个段空间占用，http请求类型ID每毫秒4096个sequence,一毫秒内产生ID不足,则剩下的sequence就浪费了。所以把时间精度设定为秒，然后把sequence字段增加。这样同样做到每秒钟超过百万的sequence可用，而且能省出3个bit空间给机器work ID用。

生成完全本地化，无需联网即可生成数值型ID。

不同工作模式的举例：

公司短域名系统,因为以前开发时就使用了数值类型的ID。现在采用分布式ID生成方案,为了兼容以前数值类型的ID，我们使用远程HTTP请求方式获取GUID。这样既兼容以前系统设计,又能正常获取GUID。

而在本机测试时，有可能不在办公环境，连不到远程GUID服务器。这时可以使用本地伪GUID方案，进行调试。等开发完成到正式环境再使用远程HTTP请求方式获取GUID。

而我们新开发的ceph管理系统中，因为是一个全新系统，不需要考虑ID和以前版本的兼容性，我们采用了字符串类型ID，这样既提高了效率，又减减少了系统复杂度。

Claims (9)

1.一种分布式全局唯一ID应用方法，包括以下两种类型：字符串类型的全局唯一ID，能够在没有网络情况下本地高效生成时间友好的全局唯一ID；数值型全局唯一ID，需要有网络通讯这一前提，从远程服务器获取数值型、时间友好的全局唯一ID；生成数值型全局唯一ID时，整个服务分为服务端生成ID机器集群和客户端，所述服务端生成唯一ID的机器，首先需要根据机器mac地址去MySQL数据库集群进行注册，获取服务机器唯一编号，保证服务端各个机器生成ID唯一；客户端通过增加缓存使得用户请求无感知。客户端和服务器通过HTTP请求进行数据交互。

2.根据权利要求1所述的分布式全局唯一ID应用方法，其特征在于：本地生成的字符串类型全局唯一ID，由110位数据组成，包括最高48位的时间位、中间48位的机器唯一标示位、最低14位的序列号位，并通过32进制编码将数据压缩成一个22字符长度的字符串,实现在无网络环境下生成短小无特殊字符全局唯一ID。

3.根据权利要求1所述的分布式全局唯一ID应用方法，其特征在于：远程获取的数值型全局唯一ID通过MySQL数据库的自增主键和唯一主键进行处理，服务启动时,本方法根据机器mac地址去MySQL数据库集群进行注册，如果此mac地址已经注册过，则直接返回该机器已经注册过得编号；如果发现没有注册过，则插入一条记录，并返回id作为编号，从而使每台电脑都能得到一个唯一的编号。

4.根据权利要求1所述的分布式全局唯一ID应用方法，其特征在于：远程获取的数值型全局唯一ID使用户请求无感知，通过在客户端增加缓存,每次请求都从服务器端批量获取数据，做到在现多线程情况下远程调用无感知的获取全局唯一ID。

5.根据权利要求4所述的分布式全局唯一ID应用方法，其特征在于：所述客户端设有一个缓存队列，并单独使用一个worker线程请求服务端获取全局ID，消费线程每消费一个,worker线程就会往缓存队列里面放一个；当worker线程出现网络异常时,会首先进行重试,多次尝试依然失败后,会往缓存队列里面存放特殊岗哨对象，用于代表出现问题的标示,当消费线程发现获取的是特殊岗哨对象时,则说明work线程出现异常,然后通知上层调用者。

6.根据权利要求4所述的分布式全局唯一ID应用方法，其特征在于：所述缓存的大小能够进行调整,最小能够调整为0,代表不使用缓存。

7.根据权利要求3所述的分布式全局唯一ID应用方法，其特征在于：远程获取的数值型全局唯一ID中，共41位，第一位保持代表正数的0，依次包括41位时间戳、10位workID、12位序列号位。

8.根据权利要求7所述的分布式全局唯一ID应用方法，其特征在于：所述序列号为初始随机、顺序递增形式，当服务器出现时间回退时,生成序列号时间不会回退，会继续使用上一次使用最晚时间；当一毫秒以内序列号大于最大标示4096以后，会使用下一毫秒的序列号,毫秒数会加一，序列号继续从0开始。

9.根据权利要求1所述的分布式全局唯一ID应用方法，其特征在于：在连不到网络的测试环境中或者为了兼容以前数值类型的ID，还能够采用远程HTTP请求方式获取唯一ID，远程HTTP请求方式获取的唯一ID使用long类型的64bit，第一位保持0，后面依次由30bit时间段、13bit的伪进程标识段、20bit的自增sequence段组成。