CN110619114B - 流水号生成方法及系统 - Google Patents

Abstract

本申请实施例提供了一种流水号生成方法及系统，通过网关设备响应于流水号生成请求，获得业务编码，并且根据接收到流水号生成请求时的系统时间生成时间戳。由服务节点获得该时间戳下流水号生成请求的序列号，并由服务节点根据业务编码、时间戳、预先生成的节点编码以及序列号生成与流水号生成请求对应的流水号。如此，将时间戳的生成提前到网关设备进行，由网关设备统一进行时间戳的生成，各个服务节点基于网关设备生成的时间戳进行流水号生成，保证了各个流水号的时间信息来源的唯一性，解决了不同服务节点时间不同步的问题。并且，生成的流水号中包含业务信息，利于后续业务信息的反解。

Description

流水号生成方法及系统

技术领域

本申请涉及分布式系统技术领域，具体而言，涉及一种流水号生成方法及系统。

背景技术

很多应用场景下，例如网络交易场景下，需要对每一笔交易或每一笔业务生成唯一的流水号，以对该笔业务或交易进行记录。当前有多种方式用于流水号的生成，生成的流水号也有多种不同的形式。目前，较好的方式就是利用分布式系统进行流水号生成，但是现有技术中，在利用分布式系统生成流水号时，由于各个服务节点的中央处理器(CentralProcessing Unit，CPU)时钟振荡频率的差异，不同服务节点之间时间难以完全同步，造成生成的流水号可能存在重复的现象，对业务造成严重的影响。并且，生成的流水号缺乏业务信息体现，不便于理解。

发明内容

本申请的目的包括，例如，提供了一种流水号生成方法及系统，其能够保障生成的流水号的唯一性。

本申请的实施例可以这样实现：

第一方面，本申请实施例提供一种流水号生成方法，应用于包括网关设备及多个服务节点的流水号生成系统，所述网关设备分别与各所述服务节点通信，所述方法包括：

所述网关设备响应流水号生成请求，获得业务编码；

所述网关设备获取接收到所述流水号生成请求时的系统时间，根据所述系统时间生成时间戳，将所述业务编码和所述时间戳发送至所述多个服务节点中的其中一个服务节点；

所述服务节点接收到所述业务编码和时间戳后，获得所述时间戳下所述流水号生成请求的序列号；

所述服务节点根据所述业务编码、时间戳、预先生成的节点编码以及所述序列号生成与所述流水号生成请求对应的流水号。

在可选的实施方式中，所述响应流水号生成请求，获得业务编码的步骤，包括：

在所述流水号生成请求中携带有业务参数时，所述网关设备根据所述业务参数生成对应的业务编码；

在所述流水号生成请求中未携带业务参数时，所述网关设备获得发起所述流水号生成请求的发起方的账户信息，得到与所述账户信息关联的业务编码。

在可选的实施方式中，所述获得所述时间戳下所述流水号生成请求的序列号的步骤，包括：

查询存储的时间戳是否与接收到的时间戳相同，若相同，则将存储的时间戳下的序列号增加预设值后作为所述流水号生成请求关联的序列号，并将该序列号存储；

若存储的时间戳小于接收到的时间戳，则将存储的时间戳更新为接收到的时间戳，并将更新后的时间戳存储，将预设的初始序列号作为所述流水号生成请求关联的序列号，并将该序列号进行存储。

在可选的实施方式中，所述方法还包括：

在生成的序列号超过预设阈值时，所述服务节点发送错误信息至所述网关设备；

所述网关设备在接收到所述错误信息后，等待预设时长并获得该预设时长后的系统时间，根据该系统时间对所述时间戳进行更新，将更新后的时间戳发送至所述服务节点；

所述服务节点基于更新后的时间戳生成序列号。

在可选的实施方式中，所述流水号生成系统还包括与所述网关设备及各所述服务节点通信的管理设备，所述方法还包括：

所述管理设备接收各个发起方发送的注册请求，对各所述发起方进行注册验证；

在注册验证成功后，从预先创建的多个业务编码中为注册验证成功的发起方分配一个业务编码，并将该业务编码与该发起方的账户信息进行关联后保存。

在可选的实施方式中，所述方法还包括：

在接收到流水号生成请求时，获得发起所述流水号生成请求的发起方的账户信息；

验证所述发起方的账户信息是否注册成功，若注册成功，则执行获得业务编码的步骤，若未注册成功，则拒绝所述流水号生成请求。

在可选的实施方式中，所述方法还包括：

所述管理设备监控所述流水号生成系统中是否存在新增的服务节点，若存在新增的服务节点，则为该新增的服务节点分配一节点编码，并将该节点编码发送至所述新增的服务节点；

所述管理设备监控所述流水号生成系统中是否存在服务节点掉线，若存在服务节点掉线，则获取该掉线的服务节点的节点编码，将该节点编码存储，以用于节点编码的重新分配。

在可选的实施方式中，所述流水号中，从高位到低位依次为所述业务编码、所述时间戳、所述节点编码以及所述序列号。

在可选的实施方式中，所述将所述业务编码和所述时间戳发送至所述多个服务节点中的其中一个服务节点的步骤，包括：

检测各所述服务节点的资源使用率，获得资源使用率最小的服务节点；

将所述业务编码和所述时间戳发送至所述资源使用率最小的服务节点。

第二方面，本申请实施例提供一种流水号生成系统，包括网关设备及多个服务节点，所述网关设备分别与各所述服务节点通信连接；

所述网关设备，用于响应流水号生成请求，获得业务编码；

所述网关设备，还用于获取接收到所述流水号生成请求时的系统时间，根据所述系统时间生成时间戳，将所述业务编码和所述时间戳发送至所述多个服务节点中的其中一个服务节点；

所述服务节点，用于接收到所述业务编码和时间戳后，获得所述时间戳下所述流水号生成请求的序列号；

所述服务节点，还用于根据所述业务编码、时间戳、预先生成的节点编码以及所述序列号生成与所述流水号生成请求对应的流水号。

本申请实施例的有益效果包括，例如：

本申请实施例提供的流水号生成方法及系统，通过网关设备响应于流水号生成请求，获得业务编码，并且根据接收到流水号生成请求时的系统时间生成时间戳。由服务节点获得该时间戳下流水号生成请求的序列号，并由服务节点根据业务编码、时间戳、预先生成的节点编码以及序列号生成与流水号生成请求对应的流水号。如此，将时间戳的生成提前到网关设备进行，由网关设备统一进行时间戳的生成，各个服务节点基于网关设备生成的时间戳进行流水号生成，保证了各个流水号的时间信息来源的唯一性，解决了不同服务节点时间不同步的问题。并且，生成的流水号中包含业务信息，利于后续业务信息的反解。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的流水号生成系统的结构框图；

图2为本申请实施例提供的流水号生成方法的流程图；

图3为本申请实施例提供的业务编码获得方法的流程图；

图4为本申请实施例提供的序列号获得方法的流程图；

图5为本申请实施例提供的流水号生成方法的另一流程图。

具体实施方式

经发明人研究发现，目前常用的流水号生成方式主要包括如下几种：

一种是利用Mysql数据库自增ID的特性，通过字段自增以及设定步长的方式，利用N个服务节点设置N个实例(N个带有自增ID字段的表)，达到唯一性流水号的效果。但是，这种方式服务节点固定、步长固定，难以进行服务节点的扩充，且对数据库具有强依赖性，同时也对数据库造成额外压力。此外，这种方式下通过自增ID方式生成的流水号，无业务意义，无法通过此类流水号反解业务意义，如业务类型、创建时间等。

另一种是采用UUID(Universally Unique Identifier，通用唯一识别码)，即结合机器的网卡、当地时间、一个随机数等信息来生成流水号，这种方式生成的流水号是无序的字符串，不具有有序性、无法保证流水号在形式上的趋势递增，从而在将其作为业务表主键或索引查询时效率较低。并且，该类流水号无业务意义，无法通过此类流水号反解其业务意义，如业务类型、业务时间等。

还有一种是采用分布式集群的方式，通过应用节点的扩展实现性能的扩展，通过时间同步服务以实现应用节点间的时间同步性。但是这种方式中，由于目前任何时间同步服务都无法完全保证被同步的应用节点的时间完全一致。而且由于各应用节点CPU时钟振荡频率的差异，在一定时间内一定会产生差异。在再次被同步时，可能存在应用节点被时间回退的现象。如此一来，该应用节点的系统时间的时间戳会瞬间倒退。若恰好该期间内生成过流水号，则会出现流水号重复的问题，造成严重的生产事故。

基于上述研究发现，本申请实施例提供一种流水号生成方案，将时间戳的生成提前到网关设备进行，由网关设备统一进行时间戳的生成，各个服务节点基于网关设备生成的时间戳进行流水号生成，保证了各个流水号的时间信息来源的唯一性，解决了不同服务节点时间不同步的问题。并且，生成的流水号中包含业务信息，利于后续业务信息的反解。

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。

因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

需要说明的是，在不冲突的情况下，本申请的实施例中的特征可以相互结合。

请参阅图1，为本申请实施例提供的一种流水号生成系统的结构框图，该流水号生成系统为一分布式系统，该分布式系统可由SpringCloud微服务架构实现。该分布式系统可包括网关设备及多个服务节点，其中，网关设备与各个服务节点通信连接。本实施例中，所述网关设备可为Zuul网关节点，所述服务节点可为主机、服务器或终端设备等，对于服务节点的硬件设备形式本实施例不作具体限制。

此外，该流水号生成系统还包括与各服务节点及网关设备通信的管理设备，该管理设备用于对系统内的各个设备进行监控、信息管理等。此外，该系统还包括除用于进行流水号生成的服务节点之外的用于处理其它业务事项的业务节点。

应当理解的是，图1所示的结构仅为流水号生成系统的结构示意图，所述流水号生成系统还可包括比图1中所示更多或者更少的组件，或者具有与图1所示不同的配置。

请参阅图2，图2示出了本申请实施例提供的流水号生成方法的流程示意图，该流水号生成方法可由图1中所示的流水号生成系统执行。应当理解，在其它实施例中，本实施例的流水号生成方法其中部分步骤的顺序可以根据实际需要相互交换，或者其中的部分步骤也可以省略或删除。该流水号生成方法的详细步骤介绍如下。

步骤S110，所述网关设备响应流水号生成请求，获得业务编码。

步骤S120，所述网关设备获取接收到所述流水号生成请求时的系统时间，根据所述系统时间生成时间戳，将所述业务编码和所述时间戳发送至所述多个服务节点中的其中一个服务节点。

步骤S130，所述服务节点接收到所述业务编码和时间戳后，获得所述时间戳下所述流水号生成请求的序列号。

步骤S140，所述服务节点根据所述业务编码、时间戳、预先生成的节点编码以及所述序列号生成与所述流水号生成请求对应的流水号。

本实施例中，网关设备所接收到的流水号生成请求可以是分布式系统之外的其它终端设备所发起的，也可以是分布式系统内的其他业务节点所发起的。

流水号属于一种通用唯一识别码(Universally Unique Identifier，UUID)，是指在一台机器上生成的数字，能够保证对在同一时空中的所有机器都是唯一的，可用于对单一业务进行标识，例如一条交易记录、一条退货记录或者是其他的业务等。

网关设备可响应流水号生成请求，并获得业务编码，其中，不同的业务类型可对应不同的业务编码，在获得业务编码的情况下，即可确定对应的业务类型。网关设备同时可根据接收到流水号生成请求时的系统时间，得到对应的时间戳。该系统时间为网关设备的本地时间，由于系统中网关设备为单一节点，各个服务节点的时间戳均有网关设备统一生成，如此，各个服务节点所生成的流水号的时间信息有唯一来源，保证了不同服务节点中时间的同步性。

由于同一时间戳下可能接收到的流水号生成请求有多条，即同一时间戳下请求同一服务节点生成多个流水号，因此，在服务节点接收到网关设备发送的时间戳和业务编码后，还可生成该时间戳下该流水号生成请求的序列号。

最后得到的流水号由业务编码、时间戳、预先生成的为该服务节点所分配的节点编码以及序列号所构成，其中，系统内任意两个服务节点的节点编码不同。如此，保障了生成的流水号的唯一性，且流水号中包含的业务信息，可用于后续业务信息的反解。

在本实施例中，在上述步骤S110中，请参阅图3，网关设备获得业务编码时，可通过以下方式获得对应的业务编码：

步骤S111，查看所述流水号生成请求中是否携带有业务参数，若携带有业务参数，则执行以下步骤S112，若未携带有业务参数，则执行以下步骤S113。

步骤S112，所述网关设备根据所述业务参数生成对应的业务编码。

步骤S113，所述网关设备获得发起所述流水号生成请求的发起方的账户信息，得到与所述账户信息关联的业务编码。

本实施例中，可以查看流水号生成请求中是否携带有业务参数，若携带有业务参数，则直接根据该业务参数生成对应的业务编码。若流水号生成请求中未携带业务参数，网关设备还可获得发起该流水号生成请求的发起方的账户信息，例如AppKey或ServiceName，进而得到与账户信息关联的业务编码。

本实施例中，业务编码可由6位数字符号进行表征，不同的业务类型具有不同的业务编码，当然应当理解，业务编码也可由5位或者是7位等数字符号表示，具体不作限制。

其中，各个发起方的账户信息与业务编码之间的关联关系可从系统中的管理设备所获得，所述管理设备预先可接收各个发起方发送的注册请求，对各发起方进行注册验证。例如，验证各个发起方的账户信息是否合法、是否具有生成流水号的权限等等，具体地可根据实际需求进行相应设置，本实施例不作具体限制。

在注册验证成功后，管理设备将从预先创建的多个业务编码中为注册验证成功的发起方分配一个业务编码，并将该业务编码与该发起方的账户信息进行关联后保存。并且，可将各个账户信息与对应的业务编码发起至网关设备，以用于后续网关设备对发起方的合法性进行验证，以及根据发起方的账户信息得到对应的业务编码。

具体地，在上述步骤S110中网关设备接收到流水号生成请求后，网关设备可获得发起该流水号生成请求的发起方的账户信息。并验证该发起方的账户信息是否注册成功，若注册成功，则继续执行获得业务编码的步骤，若未注册成功，则拒绝该流水号生成请求。

在基于流水号生成请求获得业务编码后，网关设备同时获取接收到该流水号生成请求时的系统时间，并得到对应的时间戳。本实施例中，网关设备所获得的本地时间戳的格式可为yyyyMMddHHmmssSSS格式，利用17位数字符号表示时间戳，可精确到毫秒级别。该种格式的时间戳相比现有技术中所采用的Unix时间戳而言，Unix时间戳是以1970-01-01，00:00:00开始计算到现在时间的毫秒数，对于二进制计数，目前大多数二进制时间戳以41位标识，则其最大支持时间为2039-09-07，23:47:35。之后需要再次扩展二进制占位数。而本实施例中，直接使用yyyyMMddHHmmssSSS时间格式，免去了将来为了支持更久时间而不得不进行的系统改造。另外，对比直接使用Unix十进制毫秒时间戳，采用yyyyMMddHHmmssSSS格式无疑对运维和运营人员更友好，可一目了然根据时间戳获知对应的时间信息。

网关设备在获得业务编码和时间戳之后，将业务编码和时间戳发送给系统中其中一个服务节点，由该服务节点生成对应的流水号。其中，网关设备可检测各个服务节点的资源使用率，例如CPU占用率，获得资源使用率最小的服务节点。将业务编码和时间戳发送至该资源使用率最小的服务节点，由该当前资源使用率最小的服务节点负责生成对应的流水号。

当然应当理解，在确定由哪个服务节点来处理当前的流水号生成请求时，也可以通过对系统中各个服务节点进行轮询的方式来确定，即按顺序依次由各个服务节点来处理请求。

服务节点在接收到网关设备所发送的业务编码和时间戳之后，为了避免由于在该相同的时间戳内接收到多个流水号生成请求，而导致在该时间戳内生成多个相同的流水号，因此，请参阅图4，可通过以下方式获得该时间戳下该流水号生成请求的序列号：

步骤S131，查询存储的时间戳是否与接收到的时间戳相同，若相同，则执行以下步骤S132，若存储的时间戳小于接收到的时间戳，则执行以下步骤S133。

步骤S132，将存储的时间戳下的序列号增加预设值后作为所述流水号生成请求关联的序列号，并将该序列号存储。

步骤S133，将存储的时间戳更新为接收到的时间戳，并将更新后的时间戳存储，将预设的初始序列号作为所述流水号生成请求关联的序列号，并将该序列号进行存储。

在本实施例中，可利用6位数字符号来表征毫秒时间精度下的不同的序列号，可表示000001～999999共999999个序列号，该序列号对于每个毫秒时间戳独立计数，即一个毫秒时间戳下可以得到999999个不同的序列号，可对该毫秒内接收到的999999个流水号生成请求所生成的流水号进行区分。

服务节点在每接收到一个新的时间戳时，即将该新的时间戳存储，并且，将生成的该时间戳下的序列号进行存储。因此，服务节点在接收到网关设备发送的时间戳时，可查询与已存储的时间戳是否相同，即当前时间是否与上一个流水号生成请求的时间相同。例如，当前接收到的时间戳为20190901123456000，服务节点内存中存储的时间戳为LAST_TIMESTAMP，如果LAST_TIMESTAMP＝20190901123456000，则表明在该时间戳内接收到多个流水号生成请求，需要生成多个不同的流水号。当前已生成有该时间戳下其他流水号生成请求对应的流水号，并为该流水号生成有序列号。

此种情形下，需要利用不同的序列号进行区分，可将已存储的该时间戳下的序列号增加预设值，例如1或者2等不限，将增加后的序列号作为当前的流水号生成请求对应的序列号。例如，若在时间戳20190901123456000下已生成有序列号000002，则可在该序列号基础上增加预设值1得到序列号000003，将该序列号作为当前的流水号生成请求对应的序列号。

若存储的时间戳小于接收到的时间戳，则表明该流水号生成请求为该时间戳下第一个流水号生成请求，则相应地将存储的时间戳更新为接收到的时间戳。例如，若存储的时间戳LAST_TIMESTAMP<20190901123456000，则将LAST_TIMESTAMP更新为20190901123456000。并将预设的初始序列号作为该流水号生成请求对应的序列号，例如，该预设的初始序列号可为000001。后续，可在该预设的初始序列号的基础上，通过增加初始序列号的方式，对相同时间戳下的流水号生成请求获得对应的不同的序列号。

如此，则可针对同一时间戳下需要生成的多个流水号，利用不同的序列号对该多个流水号进行区分，保证每一个流水号的唯一性。

此外，由于序列号的位数有限，在实际实施时，有可能会出现同一时间戳下的请求量很大，造成该位数有限的序列号不够用于区分该时间戳下需要生成的流水号的情况，在这种情况下，请参阅图5，可通过以下方式以避免流水号出现重复的缺陷：

步骤S210，在生成的序列号超过预设阈值时，所述服务节点发送错误信息至所述网关设备。

步骤S220，所述网关设备在接收到所述错误信息后，等待预设时长并获得该预设时长后的系统时间，根据该系统时间对所述时间戳进行更新，将更新后的时间戳发送至所述服务节点。

步骤S230，所述服务节点基于更新后的时间戳生成序列号。

本实施例中，由上述可知，序列号的位数限制了同一时间戳下可生成的序列号的个数，例如上述中以6个数字符号表示序列号时，则同一时间戳下最多可以生成999999个序列号。若生成的序列号超过预设阈值，例如超过999999，则服务节点将返回错误信息至网关设备，用于标识此次请求的序列号已达到预设的上限。

网关设备在接收到错误信息后，通过等待的方式，例如通过循环体进行时间消耗，待时间戳变更为下一个毫秒时，再将变更后的系统时间作为更新的时间戳发送至服务节点。如此，相当于将该流水号生成请求的时间戳往后延时短暂时长，服务节点再根据更新后的时间戳生成序列号，并对应生成流水号。从而，避免了在同一时间戳下请求量过大造成的唯一性流水号生成困难的问题。

在上述基础上，服务节点将根据获得的业务编码、时间戳、预先生成的节点编码以及序列号生成与流水号生成请求对应的流水号。

其中，系统中的每个服务节点具有不同的节点编码，通过不同的节点编码保证了各个服务节点之间不会生成相同的流水号。节点编码可以是服务节点向管理设备进行注册后，由管理设备分配给该服务节点的。本实施例中，可利用3位数字符号以表示不同的节点编码，则最大可承载服务节点的个数未1000个。若后续需要增加系统中服务节点的数量，则可相应地扩展节点编码的位数，从而表征更多的服务节点。如此，通过这种方式，可实现线上实时的服务节点的扩容，不需要暂停业务、不影响业务正常运行。

在本实施例中，管理设备还可实时监控流水号生成系统中是否存在新增的服务节点，若存在新增的服务节点，则为该新增的服务节点分配一节点编码，并将节点编码发送至该新增的服务节点。

并且，管理设备还可实时监控流水号生成系统中是否存在服务节点掉线，若存在服务节点掉线，则获取该掉线的服务节点的节点编码，将该节点编码存储，以用于后续节点编码的重新分配。

通过管理设备可对系统中的新增的节点、掉线的节点以及节点的编码的分配进行管理。

本实施例中，服务节点所生成的流水号中，从高位到低位依次为所述的业务编码、时间戳、节点编码以及序列号。不同的业务类型由不同的业务编码来进行区分，而其中的时间戳保证了流水号的有序性，使生成的流水号的整体趋势为递增趋势。利用流水号用于业务数据库表的主键或索引时，在保持查询/更新效率不变的情况下，其新增和删除操作的效率更高。并且，由于时间戳是yyyyMMddHHmmssSSS格式，能够判断出业务发生的时间。即本实施例所设计的流水号可反解信息，具有一定的业务意义。

并且，本实施例中，将获取时间戳的时间点提前到网关设备，由于本实施例中的网关设备为单节点，所以整个系统中生成的流水号其时间戳来源唯一，避免了服务节点之间时间不同步的问题，进一步保证了有序性。

为了执行上述实施例及各个可能的方式中的相应步骤，下面给出一种流水号生成系统的实现方式。需要说明的是，本实施例所提供的流水号生成系统，其基本原理及产生的技术效果和上述实施例相同，为简要描述，本实施例部分未提及之处，可参考上述的实施例中相应内容。该流水号生成系统包括网关设备及多个服务节点，网关设备与各个服务节点通信。

所述网关设备，用于响应流水号生成请求，获得业务编码。

所述网关设备，还用于获取接收到所述流水号生成请求时的系统时间，根据所述系统时间生成时间戳，将所述业务编码和所述时间戳发送至所述多个服务节点中的其中一个服务节点。

所述服务节点，用于接收到所述业务编码和时间戳后，获得所述时间戳下所述流水号生成请求的序列号。

所述服务节点，还用于根据所述业务编码、时间戳、预先生成的节点编码以及所述序列号生成与所述流水号生成请求对应的流水号。

本申请实施例所提供的流水号生成系统可执行本申请任意实施例所提供的流水号生成方法，具备执行方法相应的硬件设备、功能模块和有益效果。

综上所述，本申请实施例提供了一种流水号生成方法及系统，通过网关设备响应于流水号生成请求，获得业务编码，并且根据接收到流水号生成请求时的系统时间生成时间戳。由服务节点获得该时间戳下流水号生成请求的序列号，并由服务节点根据业务编码、时间戳、预先生成的节点编码以及序列号生成与流水号生成请求对应的流水号。如此，将时间戳的生成提前到网关设备进行，由网关设备统一进行时间戳的生成，各个服务节点基于网关设备生成的时间戳进行流水号生成，保证了各个流水号的时间信息来源的唯一性，解决了不同服务节点时间不同步的问题。并且，生成的流水号中包含业务信息，利于后续业务信息的反解。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (7)

1.一种流水号生成方法，其特征在于，应用于包括网关设备及多个服务节点的流水号生成系统，所述网关设备分别与各所述服务节点通信，所述网关设备为单节点，所述方法包括：

所述网关设备响应流水号生成请求，获得业务编码；

所述网关设备获取接收到所述流水号生成请求时的系统时间，根据所述系统时间生成时间戳，将所述业务编码和所述时间戳发送至所述多个服务节点中的其中一个服务节点；

所述服务节点接收到所述业务编码和时间戳后，获得所述时间戳下所述流水号生成请求的序列号；

所述服务节点根据所述业务编码、时间戳、预先生成的节点编码以及所述序列号生成与所述流水号生成请求对应的流水号；

所述业务编码通过以下方式获得：

在所述流水号生成请求中携带有业务参数时，所述网关设备根据所述业务参数生成对应的业务编码；在所述流水号生成请求中未携带业务参数时，所述网关设备获得发起所述流水号生成请求的发起方的账户信息，得到与所述账户信息关联的业务编码；

所述流水号生成系统还包括与所述网关设备及各所述服务节点通信的管理设备，所述方法还包括：

所述管理设备接收各个发起方发送的注册请求，对各所述发起方进行注册验证，在注册验证成功后，从预先创建的多个业务编码中为注册验证成功的发起方分配一个业务编码，并将该业务编码与该发起方的账户信息进行关联后保存；

所述管理设备监控所述流水号生成系统中是否存在新增的服务节点，若存在新增的服务节点，则为该新增的服务节点分配一节点编码，并将该节点编码发送至所述新增的服务节点，所述管理设备监控所述流水号生成系统中是否存在服务节点掉线，若存在服务节点掉线，则获取该掉线的服务节点的节点编码，将该节点编码存储，以用于节点编码的重新分配。

2.根据权利要求1所述的流水号生成方法，其特征在于，所述获得所述时间戳下所述流水号生成请求的序列号的步骤，包括：

查询存储的时间戳是否与接收到的时间戳相同，若相同，则将存储的时间戳下的序列号增加预设值后作为所述流水号生成请求关联的序列号，并将该序列号存储；

若存储的时间戳小于接收到的时间戳，则将存储的时间戳更新为接收到的时间戳，并将更新后的时间戳存储，将预设的初始序列号作为所述流水号生成请求关联的序列号，并将该序列号进行存储。

3.根据权利要求1所述的流水号生成方法，其特征在于，所述方法还包括：

在生成的序列号超过预设阈值时，所述服务节点发送错误信息至所述网关设备；

所述网关设备在接收到所述错误信息后，等待预设时长并获得该预设时长后的系统时间，根据该系统时间对所述时间戳进行更新，将更新后的时间戳发送至所述服务节点；

所述服务节点基于更新后的时间戳生成序列号。

4.根据权利要求1所述的流水号生成方法，其特征在于，所述方法还包括：

在接收到流水号生成请求时，获得发起所述流水号生成请求的发起方的账户信息；

验证所述发起方的账户信息是否注册成功，若注册成功，则执行获得业务编码的步骤，若未注册成功，则拒绝所述流水号生成请求。

5.根据权利要求1所述的流水号生成方法，其特征在于，所述流水号中，从高位到低位依次为所述业务编码、所述时间戳、所述节点编码以及所述序列号。

6.根据权利要求1所述的流水号生成方法，其特征在于，所述将所述业务编码和所述时间戳发送至所述多个服务节点中的其中一个服务节点的步骤，包括：

检测各所述服务节点的资源使用率，获得资源使用率最小的服务节点；

将所述业务编码和所述时间戳发送至所述资源使用率最小的服务节点。

7.一种流水号生成系统，其特征在于，所述系统适用于如权利要求1所述的方法，包括网关设备及多个服务节点，所述网关设备分别与各所述服务节点通信连接，所述网关设备为单节点；

所述网关设备，用于响应流水号生成请求，获得业务编码；

所述网关设备，还用于获取接收到所述流水号生成请求时的系统时间，根据所述系统时间生成时间戳，将所述业务编码和所述时间戳发送至所述多个服务节点中的其中一个服务节点；

所述服务节点，用于接收到所述业务编码和时间戳后，获得所述时间戳下所述流水号生成请求的序列号；

所述服务节点，还用于根据所述业务编码、时间戳、预先生成的节点编码以及所述序列号生成与所述流水号生成请求对应的流水号。

Images