CN111708775B - 自增id生成方法、装置及系统 - Google Patents

Abstract

本发明提供了自增ID生成方法、装置及系统，方法包括：接收目标服务发来的用于请求所述目标服务的自增ID的获取请求；判断存储服务器中是否保存有所述目标服务的任一一个自增ID，若是，确定所述目标服务上一次请求的自增ID，通过预设的添加数值和所述目标服务上一次请求的自增ID生成所述目标服务本次请求的自增ID。本发明的方案能够可靠的进行自增ID的生成。

Description

自增ID生成方法、装置及系统

技术领域

本发明涉及互联网技术领域，特别涉及自增ID生成方法、装置及系统。

背景技术

随着科技的进步，分布式架构与微服务技术日趋成熟，在分布式架构部署的过程中，自增ID能够用作数据总量统计或是作为数据库主键使用。

在现有技术中，在生成自增ID时，算法依赖于服务的时间，当服务器时间错误，回拨时间时有几率导致产生的id重复，因此这种方法并不能可靠地进行自增ID的生成。

申请号CN201810550002.6，发明名称为分布式全局唯一ID生成方法、装置、设备和存储介质提供了一种分布式全局唯一ID生成方法、装置、设备和存储介质，方法包括：S1：设定分布式全局唯一ID的总位数，将分布式全局唯一ID划分为若干个区间；设定每个区间的位数；所述分布式全局唯一ID由所有区间拼接而成；S2：生成时间区间位，所述时间区间位为当前毫秒长整数减去当日零点毫秒长整数；S3：根据生成请求提供的节点序列号，生成节点序列位；S4：根据配置文件中的当前序列最大值以递增方式生成并发递增位；S5：将生成请求提供的业务渠道号，做为长整数返回，生成业务渠道号；S6：将从步骤S2-S5中获得的区间位拼接获得一个全局分布式唯一ID。上述发明主要利用时间序列生成不重复的ID序列，有位数限制，需较准确评估业务量，同时需要提前分配ID区间，算法相对复杂，当服务时间有误，需要回拨时间时，有可能会造成生成的ID重复。同时位数较长，占用存储空间，非连续自增，可读性差，依然不能可靠地生成自增ID。

发明内容

本发明实施例提供了自增ID生成方法、装置及系统，能够可靠的进行自增ID的生成。

第一方面，本发明实施例提供了自增ID生成方法，包括：

接收目标服务发来的用于请求所述目标服务的自增ID的获取请求；

判断存储服务器中是否保存有所述目标服务的任一一个自增ID，若是，确定所述目标服务上一次请求的自增ID，通过预设的添加数值和所述目标服务上一次请求的自增ID生成所述目标服务本次请求的自增ID；

将所述目标服务本次请求的自增ID保存到所述存储服务器，并将所述目标服务本次请求的自增ID发送给所述目标服务。

优选地，

所述通过预设的添加数值和所述目标服务上一次请求的自增ID生成所述目标服务本次请求的自增ID，包括：在所述上一次请求的自增ID上加1生成所述目标服务本次请求的自增ID。

优选地，

该方法还包括：

当判断出所述存储服务器中没有保存所述目标服务的任一一个自增ID时，将预设的初始自增ID作为所述目标服务本次请求的自增ID，将所述本次请求的自增ID存储到所述存储服务器中，并将所述本次请求的自增ID发送给所述目标服务。

优选地，

在所述将所述目标服务本次请求的自增ID保存到所述存储服务器前，进一步包括：删除所述存储服务器中保存的所述目标服务的任一一个自增ID。

第二方面，本发明实施例提供了自增ID生成装置，包括：

接收单元和处理单元，所述接收单元和所述处理单元相连；

所述接收单元，用于接收目标服务发来的用于请求所述目标服务的自增ID的获取请求；将所述目标服务本次请求的自增ID发送给所述目标服务；

所述处理单元，用于判断存储服务器中是否保存有所述目标服务的任一一个自增ID，若是，确定所述目标服务上一次请求的自增ID，通过预设的添加数值和所述目标服务上一次请求的自增ID生成所述目标服务本次请求的自增ID，将所述目标服务本次请求的自增ID保存到所述存储服务器。

优选地：

所述处理单元，在执行所述通过预设的添加数值和所述目标服务上一次请求的自增ID生成所述目标服务本次请求的自增ID时，具体执行：在所述上一次请求的自增ID上加1生成所述目标服务本次请求的自增ID。

优选地，

所述处理单元，还用于执行：当判断出所述存储服务器中没有保存所述目标服务的任一一个自增ID时，将预设的初始自增ID作为所述目标服务本次请求的自增ID，将所述本次请求的自增ID存储到所述存储服务器中，并将所述本次请求的自增ID发送给所述目标服务。

优选地，

所述处理单元，还用于在所述将所述目标服务本次请求的自增ID保存到所述存储服务器前，执行：删除所述存储服务器中保存的所述目标服务的任一一个自增ID。

第三方面，本发明实施例提供了自增ID生成系统，包括：上述第二方面中任一提供的自增ID生成装置及存储服务器；

所述存储服务器与所述自增ID生成装置相连；

所述存储服务器，用于保存至少一个服务的至少一个自增ID。

优选地，

所述自增ID生成系统，还包括：获取接口；

所述获取接口，用于连接至少一个服务，以使所述服务通过所述获取接口发送获取请求。

本发明实施例提供了自增ID生成方法、装置及系统，方法包括：接收目标服务发来的请求目标服务自增ID的获取请求，之后判断存储服务器中当前是否已经保存有该目标服务的任一一个自增ID,如果保存有，确定目标服务上一次请求的自增ID，根据上一次请求的自增ID和预先设置好的添加数值生成目标服务本次请求的自增ID，将本次请求的自增ID保存到存储服务器，并将将本次请求的自增ID发送给所述目标服务。如今对于自增ID的解决方案严重依赖于本地时间戳来生成自增ID，未考虑本地服务时间错误，回拨时间可能会造成自增ID生成重复的情况，生成方法并不可靠。本发明提供的方案通过获取在存储服务器中保存的目标服务的上次请求的自增ID与预设的添加数值来生成目标服务本次请求的自增ID，因此不会出现自增ID生成重复的现象，保证每次目标服务请求后获得的自增ID都是不重复的，能够可靠的进行自增ID的生成。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明一实施例提供的自增ID生成方法的流程图；

图2是本发明一实施例提供的自增ID生成装置的示意图；

图3是本发明一实施例提供的自增ID生成系统的示意图；

图4是本发明一实施例提供的另一种自增ID生成方法的流程图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例，基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

如图1所示，本发明一实施例提供了自增ID生成方法，包括以下步骤：

步骤101：接收目标服务发来的用于请求所述目标服务的自增ID的获取请求。

步骤102：判断存储服务器中是否保存有所述目标服务的任一一个自增ID，若是，确定所述目标服务上一次请求的自增ID，通过预设的添加数值和所述目标服务上一次请求的自增ID生成所述目标服务本次请求的自增ID。

步骤103：将所述目标服务本次请求的自增ID保存到所述存储服务器，并将所述目标服务本次请求的自增ID发送给所述目标服务。

具体来说，接收目标任务发来的表示需要获取自增ID的获取请求，当接收到获取请求时，判断存储服务服务器中是否保存有任一一个目标服务的自增ID，如果保存有，则确定目标服务上一次进行自增ID获取请求时请求的自增ID，根据上一次请求的自增ID和预先设置好的添加数值来生成目标服务本次请求的自增ID。在目标服务本次请求的自增ID生成完成后，将本次请求的自增ID保存到存储服务器，再将本次请求的自增ID发送给目标服务，完成对于目标服务请求的自增ID的生成。

在本发明一实施例中，步骤102中所述通过预设的添加数值和所述目标服务上一次请求的自增ID生成所述目标服务本次请求的自增ID，包括：在所述上一次请求的自增ID上加1生成所述目标服务本次请求的自增ID。

具体来说，当获取到了目标服务上一次请求的自增ID后，由于自增ID要保持其连续自增长的特性，因此要保证每次目标服务来请求到的自增ID和上一次请求的自增ID是连续的。因此，预先设置添加数值为1，在获取到到了目标服务上一次请求的自增ID后，再目标服务上一次请求的自增ID的数值上加1，加1后的值即为目标服务本次请求的自增ID。比如，目标服务上一次请求的自增ID为10000，在该数值上加1得到10001，则目标服务本次请求的自增ID为10001。通过加1来生成自增ID，能够保证每次目标服务请求到的自增ID都不会是重复的，而且每次都是通过加1来实现了连续和自增长。

在本发明一实施例中，该方法还可以包括：当判断出所述存储服务器中没有保存所述目标服务的任一一个自增ID时，将预设的初始自增ID作为所述目标服务本次请求的自增ID，将所述本次请求的自增ID存储到所述存储服务器中，并将所述本次请求的自增ID发送给所述目标服务。

具体来说，当存储服务器中没有保存有目标服务的任一一个自增ID时，那么需要给目标服务定一个初始自增ID，由于自增ID要大于0且全局唯一，因此可以将初始自增ID设置为一个常数，由于自增ID通常是用来进行数据总量统计或是作为数据库主键使用，因此为了便于统计和计算，可以将初始自增ID设置为1，将1作为目标服务本次请求的自增ID，并将1保存到存储服务器中，最后将1返回给目标服务。由于不同的服务的自增ID是可以重复的，因此只要判断出存储服务器中没有目标服务的任一一个自增ID时，都可以将预设的一个初始自增ID作为目标服务本次请求的自增ID，而无需设置多个初始自增ID来区分开不同的服务。

在本发明一实施例中，在所述将所述目标服务本次请求的自增ID保存到所述存储服务器前，还包括：删除所述存储服务器中保存的所述目标服务的任一一个自增ID。

具体来说，由于对于目标服务的自增ID的生成只依赖于目标服务上一次请求的自增ID和预设的添加数值，因此，存储服务器中无需保存目标服务之前的一个或多个历史自增ID，保存多个自增ID有可能会加大存储服务器的存储压力，因此在保存目标服务本次请求的自增ID前，可以将存储服务器中保存的所述目标服务的任一一个自增ID删除，将本次请求的自增ID保存即可，本次请求的自增ID可以用于下一次自增ID的生成，无需保存多个之前请求的自增ID。

此外，自增ID可以使用Rdeis的string类型的key---value形式存储，不用特意的去删除上一条数据，当key相同时，会直接覆盖之前的值。在生成自增ID时，会根据不同业务设置不同的key，比如：商品设置为key1，订单设置为key2，相同的key直接存入，如果已存在，会直接覆盖上一个值，无需特意的去删除自增ID，提高了处理效率。

在现有技术中，众多解决方案中严重依赖本地时间戳生成ID，未考虑本地服务时间错误，回拨时间可能造成生成ID重复的情况，生成的ID为位数较长，非连续自增长，可读性差。为了达到全局唯一，通常利用Zookper和Mysql进行注册管理。本发明使用了Redis作为存储服务器，Zookper和Mysql在性能上都不如Redis，无法满足高并发请求。Redis作为常用的缓存中间件，具有单线程高并发的特性，用来存储ID可以使安全性和性能方面得到保证。本发明提供的方法可以通过Redis执行Lua脚本来进行实现。Lua作为一种轻量小巧的脚本语言，对各类系统具有很好的支持，常用于嵌入各类应用程序中，扩展程序功能。Redis从2.6.0版本开始支持Lua脚本，将自增算法封装于Lua脚本中，Redis在执行Lua脚本时将不会执行其他命令，在高并发请求的情况下也能保证了获取到的ID唯一且可靠。

分布式全局唯一自增ID可用于统计分布式系统数据总量，其全局唯一自增的特性能准确统计数据总量，当数据量达到一定级别时，每次去数据库中进行总量查询将影响系统性能，严重时将会导致系统卡死，而从Redis中查询总量，直接从内存中获取，查询效率高。例如：当我们需要统计整个系统中设备总量，并在客户端定期刷新展示时，客户端将会以一定频率定时调用接口获取数据，当设备数据很大或是调用频率高时，都将给数据库查询造成很大压力，此业务场景就可用该自增ID去做统计，每次查询从Redis中获取。自增ID还可作为数据库主键使用，无论是单一数据源库还是进行分库分表分布式架构的数据库，都可将之作为数据库主键使用。自增ID作为主键使用具有占用空间小，易排序，检索效率高的优点。全局唯一的特性可以保证不仅是表独立，而且是库独立，可以作为分库分表的分布式数据库架构表主键生成策略来使用。

如图2所示，本发明一实施例提供了自增ID生成装置，包括：

接收单元201和处理单元202，所述接收单元201和所述处理单元202相连；

所述接收单元201，用于接收目标服务发来的用于请求所述目标服务的自增ID的获取请求；将所述目标服务本次请求的自增ID发送给所述目标服务；

所述处理单元202，用于判断存储服务器中是否保存有所述目标服务的任一一个自增ID，若是，确定所述目标服务上一次请求的自增ID，通过预设的添加数值和所述目标服务上一次请求的自增ID生成所述目标服务本次请求的自增ID，将所述目标服务本次请求的自增ID保存到所述存储服务器。

在本发明一实施例中，所述处理单元202，在执行所述通过预设的添加数值和所述目标服务上一次请求的自增ID生成所述目标服务本次请求的自增ID时，具体执行：在所述上一次请求的自增ID上加1生成所述目标服务本次请求的自增ID。

在本发明一实施例中，所述处理单元202，还用于执行：当判断出所述存储服务器中没有保存所述目标服务的任一一个自增ID时，将预设的初始自增ID作为所述目标服务本次请求的自增ID，将所述本次请求的自增ID存储到所述存储服务器中，并将所述本次请求的自增ID发送给所述目标服务。

在本发明一实施例中，所述处理单元202，还用于在所述将所述目标服务本次请求的自增ID保存到所述存储服务器前，执行：删除所述存储服务器中保存的所述目标服务的任一一个自增ID。

可以理解的是，本发明实施例示意的结构并不构成对自增ID生成装置的具体限定。在本发明的另一些实施例中，自增ID生成装置可以包括比图示更多或者更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件、软件或者软件和硬件的组合来实现。

上述装置内的各单元之间的信息交互、执行过程等内容，由于与本发明方法实施例基于同一构思，具体内容可参见本发明方法实施例中的叙述，此处不再赘述。

如图3所示，本发明一实施例提供了自增ID生成系统，包括：上述实施例中任一提供的自增ID生成装置301及存储服务器302；

所述存储服务器302与所述自增ID生成装置301相连；

所述存储服务器302，用于保存至少一个服务的至少一个自增ID。

具体来说，存储服务器采用了Redis，Redis速度快，也支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储。Redis支持数据的备份，即master-slave模式的数据备份。

在自增ID生成装置接收到目标服务的获取请求时，读取Redis中有没有保存目标服务的的任一一个自增ID，如没有，则将预设的初始自增ID作为所述目标服务本次请求的自增ID，将所述本次请求的自增ID存储到所述Redis中，并将所述本次请求的自增ID发送给所述目标服务。若保存有，则在所述上一次请求的自增ID上加1生成所述目标服务本次请求的自增ID，并保存在Redis中，将加1后的生成的本次请求的自增ID发送给目标服务。

在本发明一实施例中，所述自增ID生成系统，还包括：获取接口；

所述获取接口，用于连接至少一个服务，以使所述服务通过所述获取接口发送获取请求。

具体来说，独立成一个微服务，将利用Redis执行Lua自增算法脚本的过程封装成一个微服务，对外提供获取ID接口，即获取接口。业务系统要获取自增ID时只需调用提供的获取接口即可。通过该方式，能够最大限度的与业务解耦，方便横向扩展，面对高并发请求可以集群化部署增加并发量。

为了使本发明的优点更加明显，下面通过本发明的一个较佳的实施例来详细说明。

如图4所示，本发明一实施例提供了自增ID生成方法，该方法包括以下步骤：

步骤401：目标服务通过获取接口发送自增ID的获取请求。

举例来说，目标服务为订单数据服务。预先独立成一个微服务，将利用Redis执行Lua自增算法脚本的过程封装成一个微服务，对外提供获取接口，订单数据服务需要获取自增ID时，调用该获取接口，向微服务发送自增ID的获取请求。

步骤402：判断Redis中是否保存有目标服务的任一一个自增ID，若是，确定目标服务上一次请求的自增ID，将预设的添加数值加到目标服务上一次请求的自增ID的数值上得到目标服务本次请求的自增ID，若否，将预设的初始自增ID作为目标服务本次请求的自增ID。

举例来说，当接收到订单数据服务的获取请求时，读取Redis，判断Redis中是否保存有订单数据服务的任一一个自增ID，假设当前Redis中有一个订单数据服务的自增ID10000，预设的添加数值为1，那么，在10000上加1得到10001，10001即订单数据服务本次请求的自增ID。如果Redis中没有订单数据服务的任一一个自增ID，为了方便统计，预先设置的初始自增ID为1，那么1即订单数据服务本次请求的自增ID。

步骤403：删除Redis中保存的目标服务的自增ID，将目标服务本次请求的自增ID保存到Redis，并将目标服务本次请求的自增ID发送给目标服务。

举例来说，当前Redis中保存有一个订单数据服务的一个自增ID10000，此时，将该自增ID删除，将本次请求的自增ID10001保存到Redis中，并且将10001作为订单数据服务本次请求的自增ID发送给订单数据服务。

本发明各个实施例至少具有以下优点：

1、在本发明实施例中，通过获取在存储服务器中保存的目标服务的上次请求的自增ID与预设的添加数值来生成目标服务本次请求的自增ID，因此不会出现自增ID生成重复的现象，保证每次目标服务请求后获得的自增ID都是不重复的，能够可靠的进行自增ID的生成。

2、在本发明实施例中，独立成一个微服务，将利用Redis执行Lua自增算法脚本的过程封装成一个微服务，对外提供获取ID接口，业务系统要获取自增ID时只需调用提供的接口即可。该方式最大限度的与业务解耦，方便横向扩展，面对高并发请求可以集群化部署增加并发量。

3、在本发明实施例中，由于Redis单线程的特性，在执行Lua时不必考虑并发的情况，同时基于内存的读写方式使得执行效率高，大大提高生成ID的速度。

需要说明的是，上述各流程和各系统结构图中不是所有的步骤和模块都是必须的，可以根据实际的需要忽略某些步骤或模块。各步骤的执行顺序不是固定的，可以根据需要进行调整。上述各实施例中描述的系统结构可以是物理结构，也可以是逻辑结构，即，有些模块可能由同一物理实体实现，或者，有些模块可能分由多个物理实体实现，或者，可以由多个独立设备中的某些部件共同实现。

以上各实施例中，硬件单元可以通过机械方式或电气方式实现。例如，一个硬件单元可以包括永久性专用的电路或逻辑(如专门的处理器，FPGA或ASIC)来完成相应操作。硬件单元还可以包括可编程逻辑或电路(如通用处理器或其它可编程处理器)，可以由软件进行临时的设置以完成相应操作。具体的实现方式(机械方式、或专用的永久性电路、或者临时设置的电路)可以基于成本和时间上的考虑来确定。

上文通过附图和优选实施例对本发明进行了详细展示和说明，然而本发明不限于这些已揭示的实施例，基与上述多个实施例本领域技术人员可以知晓，可以组合上述不同实施例中的代码审核手段得到本发明更多的实施例，这些实施例也在本发明的保护范围之内。

Claims (8)

1.自增ID生成方法，其特征在于，包括：

接收目标服务发来的用于请求所述目标服务的自增ID的获取请求；

判断存储服务器中是否保存有所述目标服务的任一一个自增ID，若是，确定所述目标服务上一次请求的自增ID，通过预设的添加数值和所述目标服务上一次请求的自增ID生成所述目标服务本次请求的自增ID；

将所述目标服务本次请求的自增ID保存到所述存储服务器，并将所述目标服务本次请求的自增ID发送给所述目标服务；

当判断出所述存储服务器中没有保存所述目标服务的任一一个自增ID时，将预设的初始自增ID作为所述目标服务本次请求的自增ID，将所述本次请求的自增ID存储到所述存储服务器中，并将所述本次请求的自增ID发送给所述目标服务。

2.根据权利要求1所述的方法，其特征在于，

所述通过预设的添加数值和所述目标服务上一次请求的自增ID生成所述目标服务本次请求的自增ID，包括：在所述上一次请求的自增ID上加1生成所述目标服务本次请求的自增ID。

3.根据权利要求1-2中任一所述的方法，其特征在于，

在所述将所述目标服务本次请求的自增ID保存到所述存储服务器前，进一步包括：删除所述存储服务器中保存的所述目标服务的任一一个自增ID。

4.自增ID生成装置，其特征在于，包括：

接收单元和处理单元，所述接收单元和所述处理单元相连；

所述接收单元，用于接收目标服务发来的用于请求所述目标服务的自增ID的获取请求；将所述目标服务本次请求的自增ID发送给所述目标服务；

所述处理单元，用于判断存储服务器中是否保存有所述目标服务的任一一个自增ID，若是，确定所述目标服务上一次请求的自增ID，通过预设的添加数值和所述目标服务上一次请求的自增ID生成所述目标服务本次请求的自增ID，将所述目标服务本次请求的自增ID保存到所述存储服务器；

处理单元，还用于执行：当判断出所述存储服务器中没有保存所述目标服务的任一一个自增ID时，将预设的初始自增ID作为所述目标服务本次请求的自增ID，将所述本次请求的自增ID存储到所述存储服务器中，并将所述本次请求的自增ID发送给所述目标服务。

5.根据权利要求4所述的装置，其特征在于，

所述处理单元，在执行所述通过预设的添加数值和所述目标服务上一次请求的自增ID生成所述目标服务本次请求的自增ID时，具体执行：在所述上一次请求的自增ID上加1生成所述目标服务本次请求的自增ID。

6.根据权利要求4-5中任一所述的装置，其特征在于，

所述处理单元，还用于在所述将所述目标服务本次请求的自增ID保存到所述存储服务器前，执行：删除所述存储服务器中保存的所述目标服务的任一一个自增ID。

7.自增ID生成系统，包括：权利要求4-6中任一所述的自增ID生成装置及存储服务器；

所述存储服务器与所述自增ID生成装置相连；

所述存储服务器，用于保存至少一个服务的至少一个自增ID。

8.根据权利要求7所述的系统，其特征在于，

所述自增ID生成系统，还包括：获取接口；

所述获取接口，用于连接至少一个服务，以使所述服务通过所述获取接口发送获取请求。

Images