CN117667963A - 一种分布式集群系统中生成全局唯一递增订单流水号的方法 - Google Patents

Abstract

本发明属于分布式集群系统技术领域，其公开了一种分布式集群系统中生成全局唯一递增订单流水号的方法，较好地实现全局唯一性递增订单流水号的生成，并确保CAP原则中的一致性和可靠性。本发明在分布式集群系统中，对同一类型递增流水号的微服务进行归组，并划分组内角色；并针对同一组内的每个微服务节点，制定基础配置数据，在微服务节点启动时读取所述基础配置数据，与组内其它微服务节点进行通信和进行角色自检；在分布式集群系统中，当任何一个集群中的客户端请求该集群中的微服务节点生成一个组内全局唯一递增流水号时，被请求的微服务节点判断自己的当前角色，若为领导者，则直接生成组内最新的全局唯一递增流水号，若为追随者，则向组内的领导者发送请求获取流水号。

Description

一种分布式集群系统中生成全局唯一递增订单流水号的方法

技术领域

本发明属于分布式集群系统技术领域，具体涉及一种分布式集群系统中生成全局唯一递增订单流水号的方法。

背景技术

目前，针对各种智能制造的MES管控系统，基本都是使用微服务。如果功能模块多，又会用到分布式，将各个功能模块拆分部署；如果数据量大，还会增设集群。

针对分布式+集群的场景中，经常面临生成全局唯一ID的情况，一般的做法是用一个专门的主控服务来生成订单号，下发给各个子节点微服务。但这存在一些问题：如果该主控服务发生单点故障，就会影响所有子工厂的生产。

在全局唯一ID的算法实现上，现有技术通常使用UUID、雪花ID、Raft算法等。其中，UUID和雪花ID算法并不适用于生成全局唯一递增订单流水号(从1开始，依次递加1，并且流水号全局唯一)，而Raft算法虽然能够适用生成全局唯一递增订单流水号，但是其存在性能缺陷，具体介绍如下：

UUID是一种通用唯一识别码，由特定算法生成一个32位的字符串。然而，UUID的缺点是字符串长度较长，存储空间占用较大，不满足“递增流水号”的要求。

雪花ID是一种分布式唯一ID生成算法，能够在分布式系统中生成唯一的ID，并且这些ID有一定的顺序。它通过将机器ID、数据中心ID、时间戳等信息结合起来，生成具有一定顺序的ID。但雪花ID生成的是一个Long的长数字，也不满足“递增流水号”的要求。

Raft是一种分布式一致性协议，常用于在分布式系统中实现数据的一致性。它通过选举的方式选出一个领导者，由领导者来处理所有的写请求，并将数据同步给其他的服务器。Raft的优点是在分布式系统中能够保证数据的一致性，并且通过选举的方式避免了单点故障的问题。然而，Raft的缺点是需要消耗较多的计算资源，并且实现较为复杂，可能会影响系统的性能。

Raft算法中的选举过程为：每个节点初始都在追随者状态下。如果一个追随者在一段时间内(称为election timeout，在150ms至300ms之间随机生成)没有收到领导者的心跳信息，它将会变成候选者状态，先投自己一票，并向群体内的其他节点发送选举投票请求。如果群体内的其他节点在一段任期内(称为heartbeat timeout，也是150ms至300ms之间随机生成)没有投过票，收到投票请求后将投一票给候选者，并返回。如果一个候选者收到了群体内大多数节点(N/2+1)的投票，它将变成一名领导者，选举完成，开始不断地向其他节点发送心跳检测。在此选举过程中，伴随着诸多节点间的通信，如果分组内节点很多，可能造成长时间阻塞。

此外，对于分布式集群系统而言，还需要处理好分布式的CAP原则，其中CAP即为：一致性C(Consistency)、可用性A(Availability)、分区容错性P(Partition tolerance)；要满足CAP原则，则同时满足此三个要素中的两个即可。

发明内容

本发明所要解决的技术问题是：提出一种分布式集群系统中生成全局唯一递增订单流水号的方法，较好地实现全局唯一性递增订单流水号的生成，并确保CAP原则中的一致性和可靠性。而通过进一步改进，还可解决性能开销过大的问题。

本发明解决上述技术问题采用的技术方案是：

一种分布式集群系统中生成全局唯一递增订单流水号的方法，包括以下步骤：

S1、在分布式集群系统中，对同一类型递增流水号的微服务进行归组，并划分组内角色；角色为领导者或追随者；一个组内同一时刻仅有一个微服务节点为领导者，其余为追随者；

S2、针对同一组内的每个微服务节点，制定基础配置数据，在微服务节点启动时读取所述基础配置数据，与组内其它微服务节点进行通信和进行角色自检；

S3、在分布式集群系统中，当任何一个集群中的客户端请求该集群中的微服务节点生成一个组内全局唯一递增流水号时，被请求的微服务节点判断自己的当前角色，若为领导者，则直接生成组内最新的全局唯一递增流水号，并广播给组内其它追随者，被请求的微服务节点为追随者，则向组内的领导者发送请求，领导者生成组内最新的全局唯一递增流水号，并广播给组内其它追随者。

进一步的，步骤S2中，所述基础配置数据包括组内所有微服务节点的请求路径URL以及微服务节点排序。

进一步的，步骤S2中，在微服务节点启动时读取所述基础配置数据，包括：

所述基础配置数据初始存储于独立的总控管理系统中，在微服务节点启动时，先检测自己的DB中有无基础配置数据，若无，调用接口从总控管理系统中获取，并存入自己的持久化DB中；若有，直接从自己的DB中获取。

进一步的，步骤S2中，所述与组内其它微服务节点进行通信和进行角色自检，包括：

微服务节点基于基础配置数据中的其它微服务节点的请求路径URL，与其它微服务节点进行通信，并采用如下方式进行角色自检：

通过向其它微服务节点发送请求，检测当前组内是否有领导者，如果没有，则设置自身为领导者；如果有，则设置自身为追随者。

进一步的，步骤S3中，所述领导者通过Java中具有原子特性的AtomicLong来生成组内最新的全局唯一递增流水号。

进一步的，该方法还包括步骤：

S4、当领导者发生故障后，若有追随者请求领导者，则会发生请求超时，发生超时的追随者，从其基础配置数据中，查找出组内所有微服务节点的列表信息，根据排序，读取当前领导者后面的节点，作为继任者；然后向继任者发起请求进行确认，确认成功后，继任者便升为新的领导者，新的领导者会继续从最新的流水号开始继续递增生成。

进一步的，步骤S4中，还包括：

如果继任者也有异常，则继续找下一个排序的微服务节点重复确认操作，在整个确认期间，当有一个追随者成功成为领导者后，则通过广播消息阻断其他所有组内微服务节点寻找领导者的进程。

本发明的有益效果是：

本发明方案能确保在分布式集群系统中，生成全局唯一递增流水号，同时确保分布式CAP原则的一致性和可靠性。而在领导者发生故障后，采用自定义的“继承”方法，避免了Raft算法选举过程造成的时间阻塞，整体上提高了在分布式集群系统中处理“全局唯一性”这类问题的健壮性。

附图说明

图1为实施例中的分布式集群系统环境架构示意图；

图2为实施例中请求生成全局唯一性递增流水号示意图；其中2(a)为终端向追随者请求生成递增流水号的示意图，2(b)为终端直接向领导者请求生成递增流水号的示意图；

图3为实施例中的初始化领导者示意图；

图4为实施例中的自定义新领导者产生的示意图。

具体实施方式

本发明提供了一种分布式集群系统中生成全局唯一递增订单流水号的方法，其核心是通过结合Raft算法，并对其进行改良，来较好地满足分布式CAP原则，实现全局唯一性递增订单流水号的生成。特别的，在结合Raft算法后，对其算法的领导者选举过程进行优化，以避免此过程导致的性能开销问题。

在具体实现上，本发明的方法包括以下实施手段：

1、对整个分布式集群系统中，归组同一生成类型的节点，并划分组内角色；

在分布式集群系统中，既有分布式，又有集群。生成同一类型递增流水号的微服务，可能在同一个分布式下，也可能在不同的集群中。本发明将生成同一类型递增流水号的微服务进行归组。并对它们划分角色(领导者、追随者)。

比如：对于生产订单、采购订单、销售订单，将这些不同的订单划分为不同的组。以生产订单为例，将不同子工厂(不同集群)的“生产订单微服务”(并不是同一个分布式环境下)，都归到“生产订单”组，该组内的所有微服务都参与生成全局唯一的生产订单递增流水号。一个时间点上有且仅有一个主节点来做生成的操作，称为“领导者”，组内其余节点称为“追随者”。对于采购订单、销售订单亦同理。

2、制定基础配置数据，同一组内，每个微服务在启动时进行角色自检；

对此，制订一套预配置数据，微服务在启动时，加载配置数据，获取组内其他节点信息，然后再组内通信，以此来明确自己的角色。

这套预配置数据初始存储于独立的总控管理系统中。当组内微服务启动时，先检测自己的DB中有没有配置数据，若无，调用接口从总控管理系统中获取，存入自己的持久化DB中；若有，直接从自己的DB中获取。

微服务节点获得配置数据后，根据里面的组内其余节点的URL地址，请求其他组内微服务，通过算法明确自己的角色是领导者还是追随者。如果自己是领导者，就负责生成全局唯一递增流水号，并广播给所有追随者；如果自己是追随者，就先同步领导者的最新全局唯一递增流水号。

3、自检为“领导者”的组内微服务，负责生成组内全局唯一递增流水号；

这一步直接通过Java中具有原子特性的AtomicLong来实现流水号的递增，以此来确保高并发时的生成结果全局唯一性。领导者广播最新的全局唯一递增流水号到组内所有的追随者，以保持分布式集群系统中的一致性。

4、领导者发生故障时，通过自主的“继任”方式，解决Raft算法中选举新领导者过程导致的性能开销问题；

当领导者发生故障时，Raft算法是通过选举，来产生“候选人”，再通过一系列确认动作，来产生最终的新领导者。这种选举过程会花费大量的时间开销，可能导致服务访问阻塞。对此，本发明通过自主实现的一种新的“继任”方式来避免该问题。则通过自定义的“继任”方法确定继任者，进而快速产生新的领导者。

具体的“继任”方法如下：

当领导者故障后，后续一旦有追随者请求领导者，会发生请求超时。发生超时的追随者，从预配置数据配置表中，查找出组内所有微服务列表信息。根据其中的排序，读取当前领导者后面的节点，作为继任者；然后向继任者发起请求进行确认，确认成功后，继任者便升为新的领导者。如果继任者也有异常，则继续找下一个排序的节点重复确认操作。在整个确认期间，当有一个追随者成功成为领导者后，会广播消息阻断其他所有组内节点寻找领导者的进程，以确保新领导者的唯一产生。新的领导者会继续从最新的流水号开始继续递增生成。

下面结合附图及实施例对本发明的方案作进一步的描述。

实施例

本实施例提供的分布式集群系统中生成全局唯一递增订单流水号的方法，包括如下步骤：

Step1、在分布式集群系统中，归组同一类型递增流水号的微服务；

本实施例方案的应用场景是面向多个子工厂的生产制造企业，有多种类型的递增流水号。如：生产订单递增流水号、采购订单递增流水号、销售订单递增流水号，等等。

在系统架构上，一个子工厂部署一套分布式系统；不同子工厂就对应多套分布式系统，也就是集群。参见图1，每个子工厂是一套完整的分布式微服务系统，各自拥有自己的微服务注册中心和独立的数据库。工厂总控也是一套完整独立的微服务环境。所有子工厂之间、总控和子工厂之间都采用http通信。

在这种分布式集群的系统中，将每个集群下的同类型微服务归为一组。一组负责单一类型的递增流水号。例如：一个生产制造企业有10个子工厂，对应10个集群；每个子工厂内是一套分布式，该分布式中有多个微服务，分别负责系统的各个功能模块。在每个集群的分布式中，都有一个“生产订单”微服务，该微服务用于生成该生产制造企业中全局唯一递增订单流水号。因此，将这10个子工厂的这10个生产订单微服务归为一组。

Step2、在同一组内，针对组内每个微服务，配置自主Raft算法用的基础配置数据；

该配置数据作为启动时自主Raft算法的初始化数据，具有很重要的作用。参考图3或图4的上方表格，该配置数据重点包括以下信息：组内所有微服务的请求路径URL和节点排序。

该配置数据首先存放在总控系统中，再由组内微服务在启动时拉取到自身的DB中。功能上类似于分布式配置中心的配置数据，只不过这里是多个集群向同一个“中心”拉取配置，因此存放于工厂总控系统之中。

Step3、在Step1中归组的同一组内，按照Raft算法，将组内微服务划分“领导者”、“追随者”角色。并在组内每个微服务启动时，做组内通信和角色自检，以明确自己是领导者还是追随者；

其中，领导者负责生成全局唯一的递增流水号(globalSerialNumber)，并广播给追随者。追随者不用做任何事，也不需要向领导者发送心跳检测。一个分组中有且只有一个领导者。

组内的一个微服务在启动时，先检测自己DB中是否有Step2中所述的Raft基础配置数据，如果有直接读取该数据；如果没有，向总控系统发送http接口获取，并持久化到自身DB。

其次，遍历该配置数据，找到所有子工厂的请求路径URL，并向其他所有子工厂发送请求，检测是否有领导者。如果没有，设置自身为领导者；如果有，设置自身为追随者。

再次，明确自己的身份后，要获取当前最新的流水号，如果自己是领导者，直接从持久化DB中获取自己的globalSerialNumber，作为当前最近的流水号；如果自己是追随者，则还需要向领导者调用接口，获取领导者的globalSerialNumber作为自己的globalSerialNumber。后续的递增流水号就是基于这个最近的流水号继续递增。

参见图3，广虹04厂的生产订单微服务第一个启动成功后，从工厂总控中拉取预配置列表，获得列表后，生产订单微服务从预配置列表中读取所有其它子工厂的URL地址，并分别发送请求，但由于其它子工厂的微服务没有启动，则无法收到任何反馈，此时广虹04厂的生产订单微服务将自己设为领导者，后续启动的其它子工厂的生产订单微服务在启动后，会将自己设置为追随者。

Step4、领导者通过原子性的AtomicLong来负责生成全局唯一的递增流水号globalSerialNumber，并广播给组内所有追随者；

在整个分布式集群系统中，任何一个集群中的客户端请求该集群中服务去生成一个全局唯一组内递增流水号时，请求的微服务先检测自己是否在Step1中归组的一个组内，如果在，再明确自己在组内是领导者还是追随者。如果自己是组内领导者，直接生成该组内最新的globalSerialNumber，并广播给组内其他追随者，参见图2(b)。如果自己是组内追随者，则需要发送http请求到组内领导者，领导者去生成最新的流水号后返回给该追随者，同时领导者还需要把生成的globalSerialNumber广播给组内其他所有追随者，参见图2(a)。

领导者通过Java自带的AtomicLong来负责生成这个流水号，AtomicLong对象本身具备原子性，同时具备一个原子方法incrementAndGet()，此方法能确保高并发环境下的原子操作。

Step5、加入自主实现的“继任”方法，替换Raft中的选举算法，以实现在领导者发生故障后快速产生新的领导者；

如果组内领导者出现故障，组内追随者向领导者请求时，会发生请求超时。发生请求超时的追随者都会变成发起重新设立领导者的发起者。具体就是从Step2所述的配置表中，根据排序，读取当前领导者后面的节点，作为继任者；然后向继任者发起请求进行确认，确认成功后，继任者便升为新的领导者。如果继任者也有异常，则继续找下一个排序的节点重复确认操作。在整个确认期间，当有一个追随者成功成为领导者后，会广播消息阻断组内其他所有节点寻找领导者的进程，以确保领导者的唯一。新的领导者会继续从最新的流水号开始继续递增生成。

参见图4，作为组内领导者的广虹04厂的生产订单微服务异常后，其余追随者向领导者发送请求则无响应，第一个请求超时的追随者直接从预配置列表中查询出排序在广虹04厂的下一个节点，即广虹05厂的生产订单微服务，则与其确认后，广虹05厂的生产订单微服务升为新的领导者，从而摒弃了耗性能的选举过程。

如果是追随者出现故障，则不会影响其他追随者和领导者，不用做任何处理。当该故障追随者重启后，会按照Step3中所述的方法重新确定自己追随者的身份。

如果所有节点同时故障，也不用做任何特殊处理，当任意一个节点重新启动成功时，按照Step3所述方法初始化自身角色并同步最新globalSerialNumber。

最后应当说明的是，上述实施例仅是优选实施方式，并不用以限制本发明。应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明宗旨和权利要求所保护的范围情况下，还可以做出若干修改，等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (7)

1.一种分布式集群系统中生成全局唯一递增订单流水号的方法，其特征在于，包括以下步骤：

S1、在分布式集群系统中，对同一类型递增流水号的微服务进行归组，并划分组内角色；角色为领导者或追随者；一个组内同一时刻仅有一个微服务节点为领导者，其余为追随者；

S2、针对同一组内的每个微服务节点，制定基础配置数据，在微服务节点启动时读取所述基础配置数据，与组内其它微服务节点进行通信和进行角色自检；

S3、在分布式集群系统中，当任何一个集群中的客户端请求该集群中的微服务节点生成一个组内全局唯一递增流水号时，被请求的微服务节点判断自己的当前角色，若为领导者，则直接生成组内最新的全局唯一递增流水号，并广播给组内其它追随者，被请求的微服务节点为追随者，则向组内的领导者发送请求，领导者生成组内最新的全局唯一递增流水号，并广播给组内其它追随者。

2.如权利要求1所述的一种分布式集群系统中生成全局唯一递增订单流水号的方法，其特征在于，步骤S2中，所述基础配置数据包括组内所有微服务节点的请求路径URL以及微服务节点排序。

3.如权利要求1所述的一种分布式集群系统中生成全局唯一递增订单流水号的方法，其特征在于，步骤S2中，在微服务节点启动时读取所述基础配置数据，包括：

所述基础配置数据初始存储于独立的总控管理系统中，在微服务节点启动时，先检测自己的DB中有无基础配置数据，若无，调用接口从总控管理系统中获取，并存入自己的持久化DB中；若有，直接从自己的DB中获取。

4.如权利要求2所述的一种分布式集群系统中生成全局唯一递增订单流水号的方法，其特征在于，步骤S2中，所述与组内其它微服务节点进行通信和进行角色自检，包括：

微服务节点基于基础配置数据中的其它微服务节点的请求路径URL，与其它微服务节点进行通信，并采用如下方式进行角色自检：

通过向其它微服务节点发送请求，检测当前组内是否有领导者，如果没有，则设置自身为领导者；如果有，则设置自身为追随者。

5.如权利要求1所述的一种分布式集群系统中生成全局唯一递增订单流水号的方法，其特征在于，步骤S3中，所述领导者通过Java中具有原子特性的AtomicLong来生成组内最新的全局唯一递增流水号。

6.如权利要求1-5任意一项所述的一种分布式集群系统中生成全局唯一递增订单流水号的方法，其特征在于，该方法还包括步骤：

S4、当领导者发生故障后，若有追随者请求领导者，则会发生请求超时，发生超时的追随者，从其基础配置数据中，查找出组内所有微服务节点的列表信息，根据排序，读取当前领导者后面的节点，作为继任者；然后向继任者发起请求进行确认，确认成功后，继任者便升为新的领导者，新的领导者会继续从最新的流水号开始继续递增生成。

7.如权利要求6所述的一种分布式集群系统中生成全局唯一递增订单流水号的方法，其特征在于，步骤S4中，还包括：

如果继任者也有异常，则继续找下一个排序的微服务节点重复确认操作，在整个确认期间，当有一个追随者成功成为领导者后，则通过广播消息阻断其他所有组内微服务节点寻找领导者的进程。