CN109947411A - 分布式软件生成唯一id主键的方法 - Google Patents

Abstract

本发明公开了一种分布式软件生成唯一ID主键的方法，设该唯一ID主键为CUID，CUID包括前缀码Hi和通过系统时间得到的时间戳，前缀码Hi为机器码加程序路径取哈希计算后得到的ULONG值；的方法包括以下步骤：初始化全局前缀码Hi；验证系统时间，检查本地是否有上一次CUID生成的日志文件，如果没有日志文件，则跳过检查；如果有日志文件就读取出日志文件，解析出最后一次生成CUID的时间戳，对比当前系统时间，如果最后一次生成CUID的时间大于当前系统的时间，直接抛出异常，不允许系统运行；获取SiteID信息，为每个站点分配SiteID，使每个部署的前缀码Hi唯一；生成CUID值，将前缀码Hi和当前的时间戳的字符串拼接起来。本发明确保了生成的ID的唯一性。

Description

分布式软件生成唯一ID主键的方法

技术领域

本发明涉及软件开发技术领域，特别是一种分布式软件生成唯一ID主键的方法

背景技术

大多数软件开发过程中都离不开数据库的使用，其中数据的唯一性标识变得尤为重要，需要保证每条数据都有唯一的ID标识，分布式部署的数据最后在并库的时候不会出现主键冲突。传统数据库主键的设计都是采用自增长的ID，数据库每新增加一条新的数据，主键ID都是递增的，这种自增型字段简单，存储量也不大，进行数据表单的JOIN操作性能也高，数值型ID更方便关系型数据库的快速索引。但是这样的设计有一个很大问题需要考虑，就是数据库迁移时所有的自增型ID也会变化，与之关联的其他数据就失去关联性，会造成数据混乱。另外，在分布式部署的软件中，多库合并的时候就会存在主键ID冲突的情况。比如，同一个软件部署到A、B、C三个服务器上面，每隔一段时间工具会将A、B、C的数据合并到D服务器上面去，因为ID是自增长类型的，数据迁移到D的时候，每条数据会重新构建ID，原有ID所关联的数据全部都混乱了，另外，他们三者同一个表里面的ID都是从1、2、3这样增加的，意味着三个表之间的ID主键重复的概率非常之大，不能满足多数据库同步、读写分离的需求。

自增长的主键ID不具有唯一性，而对于全局唯一标识符(GUID)算法，全局唯一标识符(GUID，Globally Unique Identifier)是一种由算法生成的二进制长度为128位的数字标识符，以下简称GUID。GUID主要用于在拥有多个节点、多台计算机的网络或系统中，在理想情况下，任何计算机和计算机集群都不会生成两个相同的GUID，GUID的总数达到了2^128(3.4×10^38)个，所以随机生成两个相同GUID的可能性非常小，但并不为0。由此可以了解到，GUID具有唯一性的特性，但它的体积相对庞大(128位长度)，结构相对复杂(不便于索引)，且可读性非常差(字符串)。

发明内容

为解决现有技术中存在的问题，本发明的目的是提供一种更安全、更可靠、更有效的算法来确保生成的ID的唯一性的分布式软件生成唯一ID主键的方法。

为实现上述目的，本发明采用的技术方案是：一种分布式软件生成唯一ID主键的方法，设该唯一ID主键为CUID，所述CUID包括前缀码Hi和通过系统时间得到的时间戳，所述前缀码Hi为机器码加程序路径取哈希计算后得到的ULONG值；所述的方法包括以下步骤：

步骤S10、初始化全局前缀码Hi，全局初始化一次，生成前缀码Hi，且所述前缀码Hi初始化之后在程序的整个生命周期保持不变；

步骤S20、验证系统时间，检查本地是否有上一次CUID生成的日志文件，如果没有日志文件，则跳过检查；如果有日志文件就读取出日志文件，解析出最后一次生成CUID的时间戳，对比当前系统时间，如果最后一次生成CUID的时间大于当前系统的时间，直接抛出异常，不允许系统运行，否则获取当前时间戳；

步骤S30、获取SiteID信息，为每个站点分配SiteID，使每个部署的前缀码Hi唯一；

步骤S40、生成CUID值，将前缀码Hi和当前的时间戳的字符串拼接起来，且在字符串中高位字节为前缀码Hi，低位字节为时间戳。

作为一种优选的实施方式，所述CUID为8个字节64位的ULONG数值类型，其中前缀码Hi占高位2个字节，时间戳占低位6个字节。

作为另一种优选的实施方式，所述前缀码Hi还可以通过WebService获取，由中心API服务进行统一分配。

作为另一种优选的实施方式，在步骤S20中，还包括对时间戳生成的时候进行加锁控制，防止并发操作。

作为另一种优选的实施方式，所述SiteID由机器名、程序路径、服务器IPAddress和机器码组成。

作为另一种优选的实施方式，还包括逆向解析CUID，将已有的CUID解析出对应的前缀码Hi值以及对应的时间戳值。

本发明的有益效果是：本发明提供更安全、更可靠、更有效的算法来确保生成的主键的ID的唯一性，并且在保证唯一性的前提下，还保证了ID的可读性、连续性、索引型、储存大小各方面的性能。

附图说明

图1为本发明实施例中初始化计算Hi的流程框图；

图2为本发明实施例中面向产品生成CUID值的流程框图；

图3为本发明实施例中通过中心API服务进行统一分配Hi的流程框图；

图4为本发明实施例中CUID的生成效果图；

图5为本发明实施例中验证系统时间和最后一次生成CUID的时间的流程框图；

图6为本发明实施例中获取唯一身份的Site ID的流程框图；

图7为本发明实施例中将前缀码Hi和时间戳拼接成CUID的示意图。

具体实施方式

下面结合附图对本发明的实施例进行详细说明。

实施例：

本发明主要基于.Net、Java、NodeJs三种开发语言环境，本实施例主要以.Net语言为基础进行介绍，另外本实施例具体以一个64位的ULONG数值类型的CUID进行详细介绍，共8个字节，为了实现递增的效果，其中时间戳占6字节，前辍码Hi占2字节，也就是说一个CUID值＝HI+时间戳，其中前缀码Hi是每个部署分配一个，保证了不同部署之间的唯一性，而时间戳是递增的，精确到微妙级别，可以确保同一个部署下产生不同的时间戳。2字节的前缀码空间可产生理论上2的16次方≈65536个前辍码，而每个部署只需分配一个Hi，前缀码不同就能决定每台机器生成不同的CUID，足以满足单个程序的分布式部署环境。

本实施例的CUID的具体算法在于：一共8字节的长度，其中高2个字节取机器标识，通过硬盘序列号计算哈希码后取低16位得到前缀码Hi。而时间戳部分是按低6个字节取系统时间，以100个Tick(Tick为万分之一毫秒)为单位，即百分之一毫秒为单位，6个字节正整数最大值为0xffff,ffff,ffff，即281474976710655。以2008-07-11 00:00:00为时间基数，则能表示的最大时间为new Date Time(2008,7,11).AddTicks(i*100)＝2097-09-20 02:56:07。高位2字节决定程序在每台机器生产不同的前缀码，低6字节决定程序在对应机器上按时间戳递增，两者合起来就能在分布式应用中产生唯一ID。

其中，64位的CUID的最大值为：1844,6744,0737,0955,1615。其对应的二进制为：

1111111111111111111111111111111111111111111111111111111111111111，前16位为高位前缀码Hi值，Hi＝65536，Hi占位2个字节，16位。后42位就是当前时间和设定的初始基数日期之间的时间戳。假设基数时间是2008-7-1100:00:00，通过计算，6个字节的时间戳可以存储的CUID有效期可以到2097-09-20 02:56:07，总寿命为89年，对于同一个产品来说可以使用89年之久。

如图1所示，下面再对本实施例实现CUID算法进行具体的介绍，包括以下步骤：

1、程序启动——初始化全局Hi

全局初始化一次，生成前缀码，以下统称Hi，Hi初始化之后在程序的整个生命周期保持不变。

本实施例中，Hi的生成有两种方式，通过枚举类型定义：CuidMode.Custom(产品自定义生成)和CuidMode.Carpa(自定义生成)；默认模式是：CuidMode.Carpa；

本实施例通过两种模式生成Hi的原因在于：Hi有2字节的存储空间，能够分配出2的16次方个不同的Hi，大约65,535个，并且由CuidMod.Carpa模式生成的Hi是按机器码+程序路径取Hash计算后得到的ULONG值，这个Hi不是有序生成的，比如产品a是1000个部署，产品b有1000个部署；虽然他们一共才消耗2000个Hi，但这2000个Hi是无序的，Hash取值可能会出现重复，Hi一旦出现重复，对产品来说是严重bug，两个不同的部署出现相同Hi，那他们生产出来的数据，基本上都会有重复了。因此，使用自定义生成Hi的方式不适合多部署的产品，仅适合单部署或少量部署(保证机器码唯一)，且需要预先验证每个部署下的Hi是否有重复(每个部署检查一次就行了，因为算法是按机器码+程序路径计算好的，这两者对于已经验证过的产品来说都是常量)。

对于分布式多部署的产品，Hi的生成方式如图3所示：算法提供接口，产品实现接口，每个产品在初始化启动的时候，检查本地是否有缓存的Hi(文件)，如果没有就通过如图1所示的注册的接口ICuidHiGetter获取Hi，为了确保Hi的唯一性，产品还需要单独提供一个中心API服务，统一分配Hi，也就需要通过WebService获取Hi，由中心服务统一调度管理Hi的分配，确保每个不同产品，不同部署分配不同的Hi，各个部署获取到Hi之后就缓存到本地Hi文件中，下次启动就不需要获取Hi；不管是本地获取Hi还是通过API获取的Hi，产品初始化的时候都要传给本实施例如图1所示的Cuid.Hi进行全局缓存。

2、验证系统时间

通过上述介绍，由于CUID另一部分是由时间戳构造的，即系统的时间对生成的CUID的唯一性也非常关键。

如图2所示，CUID生成中，本实施例会先对当前系统时间进行验证：程序启动，检查本地是否有上一次CUID生成的日志文件，如果没有日志文件，则跳过检查；如果有日志文件就读取出日志文件，解析出最后一次生成CUID的时间戳，对比当前系统时间，如果最后一次生成CUID的时间大于当前系统的时间，这是不合理的，直接抛出异常，不允许系统运行，原因是系统的时间被人为修改，而且修改后的系统时间是不应该小于上一次生成CUID的时间。当然，如果是误操作的，比如测试情况，只需要手动删除该日志文件，重启程序就正常了。

另外，由于本实施例的CUID由48位时间戳组成，这也是有限的，这个容量预计可以生成大约90年的时间戳。既然时间戳区间有限的，那么本算法就需要考虑过去的时间，设定一个默认日期作为基数，在此日期基数的基础上加90年，就可以让产品的CUID使用寿命增加。比如本算法是2019年实现的，那基数就以本算法创建之日起算，而不是按1900年来计算，否则48位长度早就已经过期，如图5所示。

3、获取产品SiteID信息(机器码+程序路径等)

第1步里面谈到Hi的生成方式有两种，其中由本算法自定义生成生成Hi的方式需要获取机器码和程序部署的路径，因为同一台机器可能有多个不同的部署，但他们都读写同一个数据库，数据的ID都是CUID，所以同一个服务器环境存在多个产品的时候，需要根据产品的路径来确定，也需要由机器码和程序所在路径来定义Hi值。这里的组合，统称为SiteID，也就是每个站点分配一个SiteID，这个SiteID是按机器码和程序路径来定义的，当然还可以由产品配置指定。

但是，某些服务器机器码是相同的，甚至无法获取到机器码，比如阿里云服务器，虚拟主机等，也就是说不通的主机机器码可能相同的或者是空的。这种时候就需要使到用其他机器的信息，比如操作系统计算机名称，每台虚拟主机是不通的名称。同时，每台虚拟主机有不通的服务器IP。

由此，如图6所示，本实施例的SiteID最终是由，机器名+程序路径+服务器IPAddress+机器码组成，每个产品拥有了唯一的SiteID。

4、多线程需要加锁

如图2所示，生成CUID的时间戳部分时，由于多进程的关系，可能有并发请求，子进程等业务，避免同一时刻多个任务操作同一个数据，因此，时间戳生成的时候需要加锁控制，本算法的时间戳的生成时非常快的，主要目的是防止并发操作。

5、生成CUID值

该步骤负责输出唯一ID，对外提供的公用接口，具体的，通过移位运算，数字的相加就能生成唯一ID，性能非常的优化。如图7所示，通过上面的几个步骤，都是在程序初始化的过程中就做了，也就是说全局仅做一次，而且很快完成，性能上不会对生成CUID值造成任何影响。生成CUID的时候是根据全局生成的Hi和当前时间戳两者合并而成的，虽然是两个ULONG数字相加，但其实是类似于两个字符串的拼接。只要保证了每个部署的前缀码Hi唯一，生成的CUID就是唯一的了。本实施例是将Hi通过移位算法(性能最优)，把Hi的值填充到CUID的前面两个字节中，后面6个字节才是时间戳，也就说前两个字节的数据是Hi，起着至关重要的作用，唯一性由它决定，后面6字节的时间戳只是起到递增的效果，CUID的生成效果如图4所示。

6、逆向解析CUID

该步骤主要是为了在后续排查CUID的问题，导致CUID出现重复。而逆向解析就是顺着CUID生成的反方向思路来，将已有的CUID解析出对应的Hi值，对应的时间戳值，就能确定该CUID值由哪个机器生成，什么时候生成的，就能够很好的锁定问题发生的时间和具体的部署，最后就能确定是那台机器人为配置有误。

当然，本算法经过几次优化之后，已经不需要任何配置了，上述也介绍了本实施例中Hi的生成就两种模式，一种是内部根据机器信息站点信息生成，无需人工配置，另一种模式是产品通过接口统一分配Hi。其中第二种模式可能会因为产品的使用不当出现问题，所以逆向解析功能还是有一定作用。

7、程序结束

第2步里面，程序启动的时候要做系统时间和最后一次CUID生成时间的比较，如果最后一次生成的CUID保存时间和当前程序启动的时间有冲突，不合理的情况会中断程序执行，并抛出异常提示。那么，这个最后一次生成CUID的时间就需要记录到当前程序的日志文件中。通过注册DomainUnload、UnhandledException、ProcessExit这三个事件，可以在程序退出的时候写日志。

下面通过具体的循环生成100个、1000个、10000个、100000个CUID对本实施例进行验证：

测试用例的测试代码如下：

测试结果如下：

100

总耗时：176

1000

总耗时：0

10000

总耗时：2

100000

总耗时：15

1000000

总耗时：145

10000000

总耗时：1467

上面第一次生成耗时176毫秒，原因是第一次生成会先计算Hi值。由此可见，一次生成1000个唯一的ID值，0毫秒就完成了。生成1万个ID值仅需2毫秒，性能是非常优化的。

生成的部分CUID值如下：

5858087028566932718

5858087028566932771

5858087028566932779

5858087028566932787

5858087028566932793

5858087028566932798

5858087028566932803

5858087028566932807

5858087028566932812

5858087028566932825

上述最后一个CUID值为：5858087028566932825，通过逆向解析可查看它所携带的信息，如下所示：

由上述可以看出当前机器生成的Hi为20812，生成的具体时间精确到毫秒为2017-12-21 22∶37∶27.601时刻。

下面测试多线程环境下生成CUID值，测试3个线程，每个线程独立生成10000个CUID值，测试无重复率，多线程环境下测试生成的部分CUID值如下所示：

线程ID：13 CUID：5858087032288981585

线程ID：11 CUID：5858087032288981622

线程ID：11 CUID：5858087032288981695

线程ID：11 CUID：5858087032288981715

线程ID：11 CUID：5858087032288981734

线程ID：11 CUID：5858087032288981754

线程ID：11 CUID：5858087032288981773

线程ID：11 CUID：5858087032288981792

线程ID：11 CUID：5858087032288981812

线程ID：11 CUID：5858087032288981831

线程ID：11 CUID：5858087032288981850

线程ID：11 CUID：5858087032288981870

线程ID：11 CUID：5858087032288981889

线程ID：11 CUID：5858087032288981908

线程ID：11 CUID：5858087032288981928

线程ID：11 CUID：5858087032288981947

线程ID：11 CUID：5858087032288981966

线程ID：12 CUID：5858087032288981662

线程ID：12 CUID：5858087032288982008

线程ID：12 CUID：5858087032288982028

线程ID：12 CUID：5858087032288982047

线程ID：12 CUID：5858087032288982076

线程ID：13 CUID：5858087032288981675

线程ID：13 CUID：5858087032288982189

线程ID：12 CUID：5858087032288982138

线程ID：12 CUID：5858087032288982281

线程ID：12 CUID：5858087032288982321

线程ID：11 CUID：5858087032288981988

线程ID：11 CUID：5858087032288982421

线程ID：11 CUID：5858087032288982487

线程ID：13 CUID：5858087032288982240

线程ID：12 CUID：5858087032288982372

线程ID：12 CUID：5858087032288982690

线程ID：12 CUID：5858087032288982753

线程ID：12 CUID：5858087032288982831

线程ID：12 CUID：5858087032288982888

线程ID：12 CUID：5858087032288982949

线程ID：12 CUID：5858087032288982993

线程ID：12 CUID：5858087032288983038

线程ID：13 CUID：5858087032288982659

线程ID：13 CUID：5858087032288983135

线程ID：13 CUID：5858087032288983172

线程ID：13 CUID：5858087032288983212

线程ID：13 CUID：5858087032288983249

线程ID：13 CUID：5858087032288983291

线程ID：13 CUID：5858087032288983330

线程ID：13 CUID：5858087032288983378

线程ID：13 CUID：5858087032288983416

线程ID：12 CUID：5858087032288983098

线程ID：13 CUID：5858087032288983456

由上述可知，本实施例所提供的分布式软件生成唯一ID主键的方法，CUID(ulong)与ID(自增型)以及GUID(string)之间具有如下表所示的优点：

	自增ID	GUID	CUID(本实施例)
				唯一性	极差	极好	极好
读写性能	极好	极差	好
				可读性	极好	极差	好
占用空间	极好	极差	一般

以上所述实施例仅表达了本发明的具体实施方式，其描述较为具体和详细，但并不能因此而理解为对本发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。

Claims (6)

1.一种分布式软件生成唯一ID主键的方法，其特征在于，设该唯一ID主键为CUID，所述CUID包括前缀码Hi和通过系统时间得到的时间戳，所述前缀码Hi为机器码加程序路径取哈希计算后得到的ULONG值；所述的方法包括以下步骤：

步骤S10、初始化全局前缀码Hi，全局初始化一次，生成前缀码Hi，且所述前缀码Hi初始化之后在程序的整个生命周期保持不变；

步骤S20、验证系统时间，检查本地是否有上一次CUID生成的日志文件，如果没有日志文件，则跳过检查；如果有日志文件就读取出日志文件，解析出最后一次生成CUID的时间戳，对比当前系统时间，如果最后一次生成CUID的时间大于当前系统的时间，直接抛出异常，不允许系统运行，否则获取当前时间戳；

步骤S30、获取SiteID信息，为每个站点分配SiteID，使每个部署的前缀码Hi唯一；

步骤S40、生成CUID值，将前缀码Hi和当前的时间戳的字符串拼接起来，且在字符串中高位字节为前缀码Hi，低位字节为时间戳。

2.根据权利要求1所述的分布式软件生成唯一ID主键的方法，其特征在于，所述CUID为8个字节64位的ULONG数值类型，其中前缀码Hi占高位2个字节，时间戳占低位6个字节。

3.根据权利要求1或2所述的分布式软件生成唯一ID主键的方法，其特征在于，所述前缀码Hi还可以通过WebService获取，由中心API服务进行统一分配。

4.根据权利要求1所述的分布式软件生成唯一ID主键的方法，其特征在于，在步骤S20中，还包括对时间戳生成的时候进行加锁控制，防止并发操作。

5.根据权利要求3所述的分布式软件生成唯一ID主键的方法，其特征在于，所述SiteID由机器名、程序路径、服务器IPAddress和机器码组成。

6.根据权利要求1所述的分布式软件生成唯一ID主键的方法，其特征在于，还包括逆向解析CUID，将已有的CUID解析出对应的前缀码Hi值以及对应的时间戳值。