CN112199923A

CN112199923A - 基于分布式的标识生成方法、、设备及介质

Info

Publication number: CN112199923A
Application number: CN202011122844.5A
Authority: CN
Inventors: 唐明东
Original assignee: Chongqing Unisinsight Technology Co Ltd
Current assignee: Chongqing Unisinsight Technology Co Ltd
Priority date: 2020-10-20
Filing date: 2020-10-20
Publication date: 2021-01-08

Abstract

本申请提供一种基于分布式***的标识生成方法、***、设备及介质，该方法包括：获取一个或多个标识生成请求，所述标识生成请求包括业务KEY值；检测当前缓存内剩余的标识数量是否满足标识生成请求的要求；当所述缓存内剩余的标识数量满足标识生成请求的要求时，则返回所述标识给请求方；当所述缓存内剩余的标识数量不满足标识生成请求的要求时，则调用Redis INCR指令生成标识返回至缓存以满足所述标识生成请求；利用所述Redis INCR获取序列的最大值，反向计算起始值依次递增或递减生成标识，所述标识的生成数量根据所述缓存内剩余的标识数量与标识生成请求的要求确定。本申请提高了标识生成的效率；依次产生的序列ID避免了ID重复现象，有利于于后续扩容。

Description

基于分布式***的标识生成方法、***、设备及介质

技术领域

本申请涉及计算机领域，特别是涉及一种基于分布式***的标识生成方法、***、设备及介质。

背景技术

在互联网和软件开发的一些场景中，所有的数据对象都需要一个唯一标识(Identification，ID)，用来生成该ID的服务被称为ID生成器(或者发号器)。ID生成器的包括为数据对象或者其他服务发放全局唯一的ID。数据对象被分配了ID之后才能被存储和使用。

现有的ID生成器基于数据库的自增序列或者UUID(通用唯一识别码)来保证数据的唯一性。然而，当数据达到一定量级后，***将升级为分布式集群架构，一方面，如果继续采用自增序列的方式，会限制数据库节点扩容，影响ID的唯一性；另一方面，如果采用UUID方式由于其生成的ID都是无序的字符串，导致查询存储效率差，可读性差，无法保证趋势递增，也无法体现业务顺序；而如果采用Twitter开源的snowflake算法，由于其强依赖于机器时钟，当工作设备出现时钟回拨情况时，生成ID的时间戳也会随之回退，如果仍按照回退后的时间戳生成ID，则可能会出现ID重复问题；同时，多节点同一时间产生的ID差值较大，导致无法正常排序，容易造成ID资源的极大浪费。

发明内容

鉴于以上所述现有技术的缺点，本申请的目的在于提供一种基于分布式***的标识生成方法、***、设备及介质，用于解决现有技术中标识生成容易引起的ID重复以及扩展不易的问题。

为实现上述目的及其他相关目的，本申请提供一种基于分布式***的标识生成方法，包括：

获取一个或多个标识生成请求，其中，所述标识生成请求包括业务KEY值；

检测当前缓存内剩余的标识数量是否满足标识生成请求的要求；

当所述缓存内剩余的标识数量满足标识生成请求的要求时，则返回所述标识给请求方；

当所述缓存内剩余的标识数量不满足标识生成请求的要求时，则调用Redis INCR指令生成标识返回至缓存以满足所述标识生成请求；其中，利用所述Redis INCR获取序列的最大值，反向计算起始值依次递增或递减生成标识，所述标识的生成数量根据所述缓存内剩余的标识数量与标识生成请求的要求确定。

在本申请的另一目的在于提供一种基于分布式***的标识生成***，包括：

获取模块，用于获取一个或多个标识生成请求，其中，所述标识生成请求包括业务KEY值；

检测模块，用于检测当前缓存内剩余的标识数量是否满足标识生成请求的要求；

第一标识生成模块，用于当所述缓存内剩余的标识数量满足标识生成请求的要求时，则返回所述标识给请求方；

第二标识生成模块，用于当所述缓存内剩余的标识数量不满足标识生成请求的要求时，则调用Redis INCR指令生成标识返回至缓存以满足所述标识生成请求；其中，利用所述Redis INCR获取序列的最大值，反向计算起始值依次递增或递减生成标识，所述标识的生成数量根据所述缓存内剩余的标识数量与标识生成请求的要求确定。

在本申请的另一目的在于提供一种电子设备，包括：

一个或多个处理装置；

存储器，用于存储一个或多个程序；当所述一个或多个程序被所述一个或多个处理装置执行，使得所述一个或多个处理装置执行所述基于分布式***的标识生成方法。

在本申请的还一目的在于提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序用于使所述计算机执行所述基于分布式***的标识生成方法。

如上所述，本申请的基于分布式***的标识生成方法、***、设备及介质，具有以下有益效果：

本申请利用缓存提前响应标识生成请求，根据标识生成请求的要求采取不同的标识生成响应方式，一方面，提高了标识生成的效率；另一方面，依次产生的序列ID避免了ID重复现象，有利于于后续扩容；另外，能够生成满足分布式架构体系的纯数字序列ID，实现了高并发场景下快速批量生成ID的能力，跨节点的同业务多副本场景下，仍可保证ID的时序性。

附图说明

图1显示为本申请提供的一种基于分布式***的标识生成方法一实施例流程图；

图2显示为本申请提供的一种基于分布式***的标识生成方法另一实施例流程图；

图3显示为本申请提供的一种基于分布式***的标识生成***原理框架图；

图4显示为本申请提供的一种基于分布式***的标识生成***结构框图；

图5显示为本申请一实施例提供的一种电子设备的结构示意图。

具体实施方式

以下通过特定的具体实例说明本申请的实施方式，本领域技术人员可由本说明书所揭露的内容轻易地了解本申请的其他优点与功效。本申请还可以通过另外不同的具体实施方式加以实施或应用，本说明书中的各项细节也可以基于不同观点与应用，在没有背离本申请的精神下进行各种修饰或改变。需说明的是，在不冲突的情况下，以下实施例及实施例中的特征可以相互组合。

需要说明的是，以下实施例中所提供的图示仅以示意方式说明本申请的基本构想，遂图式中仅显示与本申请中有关的组件而非按照实际实施时的组件数目、形状及尺寸绘制，其实际实施时各组件的型态、数量及比例可为一种随意的改变，且其组件布局型态也可能更为复杂。

请参阅图1，为本申请提供的一种基于分布式***的标识生成方法流程图，包括：

步骤S1，获取一个或多个标识生成请求，其中，所述标识生成请求包括业务KEY值；

其中，根据业务KEY值的类型不同生成格式不同的ID序列号，例如，KEY值可根据表单名确定，其中，按照所述业务KEY值不同可生成纯数字ID序列号或带业务日期信息的ID序列号；同时，通过标识生成请求可形成单个ID序列号和批量ID序列号的获取接口。

例如，当为纯数字的ID序列号其可取值范围为1～2⁶³-1，该序列号为非固定长度，有利于后续扩容；而当带业务日期信息的ID序列号时，可采用原始KEY+日期(yyyyMMdd)+定长数字序列的固定长度。

步骤S21，检测当前缓存内剩余的标识数量是否满足标识生成请求的要求；

步骤S22，当所述缓存内剩余的标识数量满足标识生成请求的要求时，则返回所述标识给请求方；

步骤S23，当所述缓存内剩余的标识数量不满足标识生成请求的要求时，则调用Redis INCR指令生成标识返回至缓存以满足所述标识生成请求；其中，利用所述RedisINCR获取序列的最大值，反向计算起始值依次递增或递减生成标识，所述标识的生成数量根据所述缓存内剩余的标识数量与标识生成请求的要求确定。

其中，有序的标识按照时间轴依次存储在存储***中，进而存储在存储***(例如redis)中的标识是有序且单调递增的，业务***从所述存储***中获取标识，避免了由于物理机上的时间不一致造成前一个请求获取的ID反解出的时间晚于后一个请求获取的ID反解出的时间，从而避免ID不完全有序。

具体地，计算所述标识生成请求的要求数量与缓存内剩余的标识数量之间的差值；将所述缓存内剩余的标识移动至返回结果，清空缓存；所述标识的生成数量为所述缓存的最大缓存量与所述标识生成请求的要求数量与缓存内剩余的标识数量之间的差值之和；在调用方不使用KEY获取ID的情况下，例如，当检测到所述标识生成请求中不存在业务KEY值时，采用默认的业务KEY值从缓存中提取相应的ID序列号。同时提供根据KEY动态创建ID缓存池，通过本地缓存预设数量的ID，提高响应速度。

例如，使用Redis的INCR指令实现ID(标识)生成，思路简单却很实用。首先，RedisINCR指令属于原子递增操作，不论多少个客户端节点，能保证同一时间请求的ID结果是真正的顺序数字ID；其次，产生的ID序列号可以从1开始，能够做到物尽其用，不浪费ID资源；再者，不同的业务表可设置对应的KEY产生相对独立的ID，也可选择使用默认KEY共享同一组ID资源，灵活可控，有利于后续的标识的扩容。

在本实施例中，利用缓存提前响应标识生成请求，根据标识生成请求的要求采取不同的标识生成响应方式，一方面，提高了标识生成的效率；另一方面，依次产生的序列ID避免了ID重复现象，有利于于后续扩容；另外，能够生成满足分布式架构体系的纯数字序列ID，实现了高并发场景下快速批量生成ID的能力，跨节点的同业务多副本场景下，仍可保证ID的时序性。

请参阅图2，为本申请提供的一种基于分布式***的标识生成方法另一实施例流程图，包括：

步骤S31，利用主用数据库与备用数据库生成防ID重复的标识；其中，接收所述标识生成请求，检测主用数据库是否正常；

当步骤S32，所述主用数据库正常时，将所述主用数据库标识设置为第一数值；

步骤S33，当所述主用数据库异常时，切换到备用数据库使用且将所述备用数据库的标识设置为第二数值；

步骤S34，当检测到未发生时钟回拨时，将防时钟回拨标记位设置为第三数值；

步骤S35，利用主用数据库基于第一数值、KEY值、第三数值和时间戳，生成标识；

步骤S36，利用备用数据库基于第二数值、KEY值、第三数值和时间戳，生成标识。

在本实施例中，当主用数据库下线或故障时，切换至备用数据库，通过使用数据库状态标识进行切换，防止因主备一致性问题导致ID重复问题，确保了标识(ID顺序号)的唯一性。

通过上述方式有效避免了标识的重复性问题，在高可用的Redis集群环境下，此方案是一种比较完美的分布式ID生成方案，保证了标识的唯一性。

在另一个实施例中，所述标识根据业务KEY值初始的关联性，将相同类型的KEY值或相近类型的KEY值按序生成标识，鉴于KEY值之间的关联性生成可关联的标识，便于后续标识关联，有助于对标识进行管理控制。

请参阅图3，为本申请提供的一种基于分布式***的标识生成***原理框架图，包括：

1)通过应用程序提供单个ID和批量ID获取接口，便于用户获取标识生成请求；

2)连接Redis，为操作Redis做准备

3)当ID获取接口被调用时，判断入参是否有KEY，无KEY时，使用默认KEY

4)通过KEY从本地缓存中提取ID缓存池

5)判断缓存池中的ID数量是否满足调用方需求：

6)缓存数量足够时，将对应数量的ID从缓存池移动至返回结果中。

缓存数量数量不够时，将剩余缓存ID全部移动至返回结果中，清空缓存池。计算要新生成的ID数量(＝需求数量-缓存剩余数量+最大缓存数量)，调用Redis INCR指令，获取到数字序列的最大值。反向计算起始值，循环自增1，追加至返回结果中，直至满足需求数量。同样的方式，将剩余范围值填充到缓存池。

带业务日期的序列，逻辑处理上与上述步骤相似，不同点在于KEY值的处理：原始KEY+日期(yyyyMMdd)+定长数字序列；所述标识的数字序列为固定长度，例如16位，且当所述ID序列号不满足预设固定长度时，在其前方采用零补足长度；例如，数字序列部分有定长的限制，不足定长的，数字前填充0补全，超长时则抛出异常；返回结果为“日期(yyyyMMdd)+定长数字序列”格式的字符串。

在另一个实施例中，创建一个maven项目；在pom.xml文件中引入spring redis依赖；配置正确的redis连接信息；

ID生成器提供生成数字序列和日期序列的接口方法，提供ID缓存池，实现ID生成逻辑。

当应用程序产生新的业务数据需要ID序列时，调用ID生成方法，传入业务KEY值，获取对应的ID序列号。

ID生成器会优先从缓存池中提取未使用的ID资源，若资源数量不满足调用方的批量需求，则向Redis发起INCR请求，以此获取新的资源范围。然后计算并截取部分足量的ID资源与旧资源合并，返回给调用方。剩余资源则放入缓存池中，供后续使用。

请参阅图4，为本申请提供的一种基于分布式***的标识生成***结构框图；包括：

获取模块1，用于获取一个或多个标识生成请求，其中，所述标识生成请求包括业务KEY值；

检测模块2，用于检测当前缓存内剩余的标识数量是否满足标识生成请求的要求；

第一标识生成模块3，用于当所述缓存内剩余的标识数量满足标识生成请求的要求时，则返回所述标识给请求方；

第二标识生成模块4，用于当所述缓存内剩余的标识数量不满足标识生成请求的要求时，则调用Redis INCR指令生成标识返回至缓存以满足所述标识生成请求；其中，利用所述Redis INCR获取序列的最大值，反向计算起始值依次递增或递减生成标识，所述标识的生成数量根据所述缓存内剩余的标识数量与标识生成请求的要求确定.

其中，还需要说明的是，基于分布式***的标识生成***与基于分布式***的标识生成方法为一一对应的关系，在此，各个模块与上述流程步骤所涉及的技术细节与技术效果均相同，在此不用一一赘述，请参照上述基于分布式***的标识生成方法。

实施例5

下面参考图5，其示出了适于用来实现本公开实施例的电子设备(例如终端设备或服务器700的结构示意图。本公开实施例中的终端设备可以包括但不限于诸如移动电话、笔记本电脑、数字广播接收器、PDA(个人数字助理)、PAD(平板电脑)、PMP(便携式多媒体播放器)、车载终端(例如车载导航终端)等等的移动终端以及诸如数字TV、台式计算机等等的固定终端。图5示出的电子设备仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图5所示，电子设备700可以包括处理装置(例如中央处理器、图形处理器等)701，其可以根据存储在只读存储器(ROM)702中的程序或者从存储装置708加载到随机访问存储器(RAM)703中的程序而执行各种适当的动作和处理。在RAM703中，还存储有电子设备700操作所需的各种程序和数据。处理装置701、ROM702以及RAM703通过总线704彼此相连。输入/输出(I/O)接口707也连接至总线704。

通常，以下装置可以连接至I/O接口707：包括例如触摸屏、触摸板、键盘、鼠标、摄像头、麦克风、加速度计、陀螺仪等的输入装置707；包括例如液晶显示器(LCD)、扬声器、振动器等的输出装置707；包括例如磁带、硬盘等的存储装置708；以及通信装置709。通信装置709可以允许电子设备700与其他设备进行无线或有线通信以交换数据。虽然图5示出了具有各种装置的电子设备700，但是应理解的是，并不要求实施或具备所有示出的装置。可以替代地实施或具备更多或更少的装置。

特别地，根据本公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信装置709从网络上被下载和安装，或者从存储装置708被安装，或者从ROM702被安装。在该计算机程序被处理装置701执行时，执行本公开实施例的方法中限定的上述功能

需要说明的是，本公开上述的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的***、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行***、装置或者器件使用或者与其结合使用。而在本公开中，计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读信号介质可以发送、传播或者传输用于由指令执行***、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：电线、光缆、RF(射频)等等，或者上述的任意合适的组合。

上述计算机可读介质可以是上述电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。

上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被该电子设备执行时，使得该电子设备：获取数据集，所述数据集为同一人在不同场景下采集的多张人像；根据卡口设备的数量、分布的地理位置以及预设的时间段将所述数据集内的人像分配到对应的卡口设备，形成以时间顺序排列表示人像轨迹的图像，形成以时间顺序排列表示人像轨迹的图像；利用待测平台对所述图像进行聚类归档，计算所述聚类归档的指标。

可以以一种或多种程序设计语言或其组合来编写用于执行本公开的操作的计算机程序代码，上述程序设计语言包括面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。

附图中的流程图和框图，图示了按照本公开各种实施例的方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的***来实现，或者可以用专用硬件与计算机指令的组合来实现。

综上所述，本申请通过利用缓存提前响应标识生成请求，根据标识生成请求的要求采取不同的标识生成响应方式，一方面，提高了标识生成的效率；另一方面，依次产生的序列ID避免了ID重复现象，有利于于后续扩容；另外，能够生成满足分布式架构体系的纯数字序列ID，实现了高并发场景下快速批量生成ID的能力，跨节点的同业务多副本场景下，仍可保证ID的时序性。

上述实施例仅例示性说明本申请的原理及其功效，而非用于限制本申请。任何熟悉此技术的人士皆可在不违背本申请的精神及范畴下，对上述实施例进行修饰或改变。因此，举凡所属技术领域中具有通常知识者在未脱离本申请所揭示的精神与技术思想下所完成的一切等效修饰或改变，仍应由本申请的权利要求所涵盖。

Claims

1.一种基于分布式***的标识生成方法，其特征在于，所述方法包括以下步骤：

2.根据权利要求1所述的基于分布式***的标识生成方法，其特征在于，还包括：根据业务KEY值的类型不同生成格式不同的ID序列号，其中，按照所述业务KEY值不同可生成纯数字ID序列号或带业务日期信息的ID序列号。

3.根据权利要求1或2所述的基于分布式***的标识生成方法，其特征在于，所述标识的生成数量根据所述缓存内剩余的标识数量与标识生成请求的要求确定的步骤，包括：

计算所述标识生成请求的要求数量与缓存内剩余的标识数量之间的差值；

将所述缓存内剩余的标识移动至返回结果，清空缓存；

所述标识的生成数量为所述缓存的最大缓存量与所述标识生成请求的要求数量与缓存内剩余的标识数量之间的差值之和。

4.根据权利要求1或2所述的基于分布式***的标识生成方法，其特征在于，还包括：当检测到所述标识生成请求中不存在业务KEY值时，采用默认的业务KEY值从缓存中提取相应的ID序列号。

5.根据权利要求1所述的基于分布式***的标识生成方法，其特征在于，所述标识的非固定长度，且当所述ID序列号不满足预设固定长度时，在其前方采用零补足长度。

6.根据权利要求1所述的基于分布式***的标识生成方法，其特征在于，还包括：

利用主用数据库与备用数据库生成防ID重复的标识；其中，接收所述标识生成请求，检测主用数据库是否正常；

当所述主用数据库正常时，将所述主用数据库标识设置为第一数值；

当所述主用数据库异常时，切换到备用数据库使用且将所述备用数据库的标识设置为第二数值；

当检测到未发生时钟回拨时，将防时钟回拨标记位设置为第三数值；

利用主用数据库基于第一数值、KEY值、第三数值和时间戳，生成标识；

利用备用数据库基于第二数值、KEY值、第三数值和时间戳，生成标识。

7.根据权利要求1所述的基于分布式***的标识生成方法，其特征在于，还包括：所述标识根据业务KEY值初始的关联性，将相同类型的KEY值或相近类型的KEY值按序生成标识。

8.一种基于分布式***的标识生成***，其特征在于，所述***包括：

9.一种电子设备，其特征在于：包括：

一个或多个处理装置；

存储器，用于存储一个或多个程序；当所述一个或多个程序被所述一个或多个处理装置执行，使得所述一个或多个处理装置实现如1至7中任一所述基于分布式***的标识生成方法。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序用于使所述计算机执行权利要求1至7中任一所述基于分布式***的标识生成方法。