一种分布式版本管理方法、装置和系统

技术领域

本发明涉及计算机技术领域，尤其涉及一种分布式版本管理方法、装置和系统。

背景技术

对于长链路业务，其业务数据通常由多个业务子流程的消息组装得到。由于每个业务子流程具有自己独立的状态，因此业务数据会随着业务子流程的状态变化而更新。其中，长链路业务是指由多个链路串行化相加共同完成的业务，一条链路用于实现该业务的一个业务子流程。

上述长链路业务场景具有消息高并发，需要根据业务子流程的状态变化同步更新数据的特点。为了降低消息高并发所导致的乱序、重复消费消息，保障多个业务子流程的状态更新可以同步更新到业务数据，需要对业务数据进行全流程的版本管理。现有技术在进行版本管理时，通常使用分布式锁和乐观锁实现。

在实现本发明过程中，现有技术中至少存在如下问题：

现有技术的版本管理方式，在并发情况下会出现锁竞争，消耗锁资源，影响系统性能；同时在数据更新时依赖数据库，一次完整的更新过程，包含至少一次数据库查询操作和一次数据库写入操作，数据库压力大。

发明内容

有鉴于此，本发明实施例提供一种分布式版本管理方法、装置和系统，该方法通过在分布式架构下引入消息队列，使得可以串行化消费消息，同时通过统一版本信息记录多个业务节点所生成消息的消息版本，在获取到当前业务节点生成的消息时，先将该消息携带的消息版本与统一版本信息中记录的消息版本进行对比，根据对比结果确定需要更新时，再将消息写入数据库，实现了对多个业务节点的消息版本的去锁化、统一管理，避免了乱序、重复的消费消息，同时实现了一次性访问数据库，最大程度的降低了读写操作对数据库压力。

为实现上述目的，根据本发明实施例的一个方面，提供了一种分布式版本管理方法。

本发明实施例的一种分布式版本管理方法，包括：从消息队列中获取消息；其中，所述消息是当前业务节点执行业务子流程生成的，包括所述当前业务节点的节点标识和局部消息版本；根据所述节点标识，从内存存储的统一版本信息中截取与所述节点标识对应的版本字段，得到全局消息版本；其中，所述统一版本信息包括多个业务节点的消息对应的版本字段，且所述多个业务节点用于完成同一业务；将所述局部消息版本与所述全局消息版本进行比较，如果所述局部消息版本高于所述全局消息版本，则更新所述统一版本信息，将所述消息写入数据库；如果所述局部消息版本低于或等于所述全局消息版本，则删除所述消息。

可选地，所述版本字段为设定步长的二进制数值；所述根据所述节点标识，从内存存储的统一版本信息中截取与所述节点标识对应的版本字段，得到全局消息版本，包括：根据所述节点标识和所述步长，确定所述消息对应的版本字段在统一版本信息中占据的位置；使用位运算，从所述统一版本信息中截取所述位置的二进制数值，将截取的所述二进制数值作为所述全局消息版本。

可选地，所述使用位运算，从所述统一版本信息中截取所述位置的二进制数值，包括：生成二进制字符串；其中，所述二进制字符串的位数与所述统一版本信息的位数相同，且所述二进制字符串中与所述位置对应二进制位的取值为1，其余二进制位的取值为0；将所述统一版本信息与所述二进制字符串进行按位与运算，得到所述位置的二进制数值。

可选地，所述消息包括主键；所述从内存存储的统一版本信息中截取与所述节点标识对应的版本字段的步骤之前，所述方法还包括：根据设定的关联关系，查找所述主键对应的统一版本信息，确定查找失败；其中，所述关联关系用于记录所述主键和所述统一版本信息之间的对应关系；根据所述节点标识和所述局部消息版本，生成所述统一版本信息，将所述统一版本信息存储到内存。

可选地，所述根据所述节点标识和所述局部消息版本，生成所述统一版本信息，包括：根据设定步长，将所述局部消息版本转换为对应的二进制数值；将所述二进制数值填充到所述节点标识对应的版本字段，将剩余的版本字段填充为0，得到所述统一版本信息。

可选地，所述消息队列用于存储来自所述多个业务节点的、具有相同主键的消息；所述消息是根据预设的哈希函数和所述主键，分发到所述消息队列的。

可选地，所述方法还包括：将更新后的所述统一版本信息同步到远程数据库中，更新所述消息队列的偏移量。

为实现上述目的，根据本发明实施例的另一方面，提供了一种分布式版本管理装置。

本发明实施例的一种分布式版本管理装置，包括：消息获取模块，用于从消息队列中获取消息；其中，所述消息是当前业务节点执行业务子流程生成的，包括所述当前业务节点的节点标识和局部消息版本；版本截取模块，用于根据所述节点标识，从内存存储的统一版本信息中截取与所述节点标识对应的版本字段，得到全局消息版本；其中，所述统一版本信息包括多个业务节点的消息对应的版本字段，且所述多个业务节点用于完成同一业务；比较处理模块，用于将所述局部消息版本与所述全局消息版本进行比较，如果所述局部消息版本高于所述全局消息版本，则更新所述统一版本信息，将所述消息写入数据库；如果所述局部消息版本低于或等于所述全局消息版本，则删除所述消息。

可选地，所述版本字段为设定步长的二进制数值；所述版本截取模块，还用于根据所述节点标识和所述步长，确定所述消息对应的版本字段在统一版本信息中占据的位置；以及使用位运算，从所述统一版本信息中截取所述位置的二进制数值，将截取的所述二进制数值作为所述全局消息版本。

可选地，所述版本截取模块，还用于生成二进制字符串；其中，所述二进制字符串的位数与所述统一版本信息的位数相同，且所述二进制字符串中与所述位置对应二进制位的取值为1，其余二进制位的取值为0；以及将所述统一版本信息与所述二进制字符串进行按位与运算，得到所述位置的二进制数值。

可选地，所述消息包括主键；所述装置还包括：查找处理模块，用于根据设定的关联关系，查找所述主键对应的统一版本信息，确定查找失败；其中，所述关联关系用于记录所述主键和所述统一版本信息之间的对应关系；以及根据所述节点标识和所述局部消息版本，生成所述统一版本信息，将所述统一版本信息存储到内存。

可选地，所述查找处理模块，还用于：根据设定步长，将所述局部消息版本转换为对应的二进制数值；以及将所述二进制数值填充到所述节点标识对应的版本字段，将剩余的版本字段填充为0，得到所述统一版本信息。

可选地，所述消息队列用于存储来自所述多个业务节点的、具有相同主键的消息；所述消息是根据预设的哈希函数和所述主键，分发到所述消息队列的。

可选地，所述装置还包括：更新同步模块，用于将更新后的所述统一版本信息同步到远程数据库中，更新所述消息队列的偏移量。

为实现上述目的，根据本发明实施例的又一方面，提供了一种分布式版本管理系统。

本发明实施例的一种分布式版本管理系统，包括：分布式版本管理装置和消息中间件；其中，所述消息中间件，用于接收来自多个业务节点的消息，根据预设的哈希函数和所述消息的主键，将所述消息分发至对应的消息队列。

可选地，所述哈希函数用于将所述主键与设定倍数的消息队列的数量进行取余运算。

为实现上述目的，根据本发明实施例的再一方面，提供了一种电子设备。

本发明实施例的一种电子设备，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现本发明实施例的一种分布式版本管理方法。

为实现上述目的，根据本发明实施例的再一方面，提供了一种计算机可读介质。

本发明实施例的一种计算机可读介质，其上存储有计算机程序，所述程序被处理器执行时实现本发明实施例的一种分布式版本管理方法。

上述发明中的一个实施例具有如下优点或有益效果：通过统一版本信息记录多个业务节点所生成消息的消息版本，在获取到当前业务节点生成的消息时，先将该消息携带的消息版本与统一版本信息中记录的消息版本进行对比，根据对比结果确定需要更新时，再将消息写入数据库，实现了对多个业务节点的消息版本的去锁化、统一管理，避免了乱序、重复的消费消息，同时实现了一次性访问数据库，最大程度的降低了读写操作对数据库压力。

使用二进制数值构建统一版本信息，使得可以通过位运算截取统一版本信息中节点标识对应的版本字段，进而与消息中携带的消息版本比较版本高低，无需与数据库进行多版本对比，实现版本管理。根据确定的位置，生成与统一版本信息的位数相同的二进制字符串，进而将该二进制字符串与统一版本信息进行按位与运算，即可截取到节点标识对应的版本字段。

在获取到消息后，先根据消息的主键查找对应的统一版本信息，如果未能查找到主键对应的统一版本信息，说明是首次从消息队列获取具有该主键的消息，需要按照节点标识和消息版本生成统一版本信息，便于获取到新消息时，进行版本比对。通过将消息中携带的消息版本转换为二进制，提高计算效率。

通过将不同业务节点的消息，按照主键和哈希函数分发到不同的消息队列，使得相同主键的消息发送到同一消息队列，在消费消息时，仅有一台机器能够获取到该消息，实现了并发消息的串行化处理，避免资源竞争，提高系统的并发处理能力。在消息写入数据库成功后，将更新后的统一版本信息同步到远程数据库，并更新消息队列的偏移量，保障整体数据的一致性和服务的高可用性。

上述的非惯用的可选方式所具有的进一步效果将在下文中结合具体实施方式加以说明。

附图说明

附图用于更好地理解本发明，不构成对本发明的不当限定。其中：

图1是订单业务中履约数据所对应宽表的结构示意图；

图2是订单业务的业务数据进行数据更新的原理示意图；

图3是根据本发明实施例的分布式版本管理方法的主要步骤的示意图；

图4是根据本发明实施例的分布式版本管理方法的系统架构示意图；

图5是根据本发明实施例的分布式版本管理方法的主要流程示意图；

图6是根据本发明实施例的分布式版本管理方法中统一版本信息的更新原理示意图；

图7是根据本发明实施例的分布式版本管理装置的主要模块的示意图；

图8是本发明实施例可以应用于其中的示例性系统架构图；

图9是适用于来实现本发明实施例的电子设备的计算机装置的结构示意图。

具体实施方式

以下结合附图对本发明的示范性实施例做出说明，其中包括本发明实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本发明的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

如背景技术所述，长链路业务的业务数据是由多个业务子流程的消息组装得到。具体地，长链路业务由多个业务节点实现，将每个业务节点执行各自业务子流程所生成的数据组装为宽表，即可得到对应的业务数据。其中，宽表是字段比较多的数据库表，通常是指与业务主题相关的指标、维度、属性关联在一起的一张数据库表。

以订单业务为例，实现该业务的业务节点包含但不限于：下单支付节点、生产节点和配送节点。其中，下单支付节点用于实现订单下单、订单支付、订单拆分、订单调度等下单子流程；生产节点用于实现拣货、打包等生产子流程；配送节点用于实现货物配送的配送子流程。

如果需要对全链路的数据进行监控，比如对全链路的履约数据进行分析，寻找某些业务节点的履约超时信息，就需要存储订单上下游的相关消息，并进行聚合统计分析。其中，履约数据是指从订单交易生成到订单交易结束这一完整生命周期过程中所产生的数据，包括订单数据、生产数据、配送数据等。

图1是订单业务的履约数据所对应的宽表的结构。由图1可知，该宽表由订单数据字段、生产数据字段和配送数据字段组成。订单数据字段包括订单创建时间、支付时间、订单金额、订单状态等信息；生产数据字段包括订单下传时间、最终拣货时间、拣货完成时间、打包完成时间、拣货单状态等信息；配送数据字段配送员、配送状态、用户期望最晚送达时间、自提配送标识等信息。

由于长链路业务的宽表由多个业务子流程的消息加工而成，每个业务子流程的消息占用宽表的部分字段。如图2，订单业务的宽表包括field1、field2、……、field30字段，这些字段由消息1(包含field1、field2、……、field10字段)、消息2(包含field11、field12、……、field20字段)和消息3(包含field21、field22、……、field30字段)加工而成。

另外，图2中，ES是搜索引擎，英文全称为Elasticsearch。MySQL、ClickHouse、HBase均为数据库。status1表示消息来自于下单支付节点，status2表示消息来自于生产节点，status3表示消息来自于配送节点。

由于业务子流程的消息到达时间的不确定性，会带来分布式消费下的高并发、乱序等问题。同时，由于每个业务子流程具有自己独立的状态，因此整个宽表的数据更新会随着业务子流程的状态变化而更新，需要对宽表数据进行多状态管理。比如，生产子流程的消息更新时，需更新宽表；配送子流程的消息更新时，也需更新宽表。

针对上述特定业务场景，需要处理好由于消息高并发，带来的乱序、重复消费消息的问题，减少对数据库的冲击；同时也要保证每个业务子流程的状态更新可以同步到宽表，实现全流程的版本控制，防止数据状态回滚。为实现上述目标，现有技术中通过引入锁机制(包括分布式锁和乐观锁)对宽表数据的状态进行了版本管理。

其中，分布式锁方式在接收到消息时，需先用分布式锁锁住主键，之后查询数据库中该消息的状态，将查询出的状态与消息携带的状态对比，并在需要更新时，将消息写入数据库。乐观锁方式在接收到消息时，需先从数据库中读取消息(包括版本号)，在准备更新时，判断数据库中该消息的当前版本号与读取的版本号是否一致，并在两者一致时，版本号自增，将消息写入数据库。

但是锁机制在并发情况下会出现锁竞争(即抢占锁)，消耗锁资源，并发失败率高，需要额外重试，影响系统性能；同时在数据更新时依赖数据库，一次完整的更新过程，包含至少一次数据库查询操作和一次数据库写入操作，数据库压力大。因此，本发明实施例提供了一种分布式版本管理方法，该方法实现了去锁化，避免了上述各种问题，具体实现如下。

图3是根据本发明实施例的分布式版本管理方法的主要步骤的示意图。如图3所示，本发明实施例的分布式版本管理方法，由分布式版本管理装置实现，主要包括如下步骤：

步骤S301：从消息队列中获取消息。当前业务节点作为消息的生产者，在执行其业务子流程时会生成消息，该消息中可以包括当前业务节点的节点标识和局部消息版本。消息生成后，会被发送到消息中间件，由消息中间件将其存储到消息队列。其中，局部消息版本是指当前业务节点所生成消息的版本。

分布式版本管理装置作为消息的消费者，可以基于生产消费者模式或者发布订阅模式，从消息队列中获取消息。以发布订阅模式为例，分布式版本管理装置向消息中间件订阅其感兴趣的消息，再由消息中间件将这些消息发送至分布式版本管理装置。

步骤S302：根据所述节点标识，从内存存储的统一版本信息中截取与所述节点标识对应的版本字段，得到全局消息版本。统一版本信息存储在内存，包括多个业务节点的消息对应的版本字段，且多个业务节点用于完成同一业务，比如用于完成同一订单。

分布式版本管理装置获取到消息后，根据消息携带的节点标识，从统一版本信息中截取对应的版本字段，即可得到全局消息版本。其中，全局消息版本是统一版本信息中记录的当前业务节点所生成消息的版本，该版本占据统一版本信息的部分字段。

以订单业务为例，该业务由三个业务节点实现，分别为下单支付节点、生产节点和配送节点，故统一版本信息包括三个版本字段，分别为下单支付节点对应的版本字段、生产节点对应的版本字段和配送节点对应的版本字段。假设统一版本信息中三个版本字段的顺序为上述顺序，如果节点标识为生产节点，则截取统一版本信息中的第二个版本字段。

步骤S303：判断所述局部消息版本是否高于所述全局消息版本，如果所述局部消息版本高于所述全局消息版本，则执行步骤S304；如果所述局部消息版本低于或等于所述全局消息版本，则执行步骤S305。该步骤用于判断消息中携带的消息版本与内存存储的消息版本的版本高低，并根据判断结果进行不同处理。

步骤S304：更新所述统一版本信息，将所述消息写入数据库，结束本流程。如果消息中携带的消息版本高于内存存储的消息版本，说明消息需要更新，则更新内存的统一版本信息，之后将该消息写入数据库。

在更新内存的统一版本信息时，需根据消息中携带的消息版本，按照统一版本信息中版本字段的生成方式，生成新的版本字段，将新的版本字段替换掉截取的版本字段，即可实现统一版本信息的更新。

步骤S305：删除所述消息，结束本流程。如果消息中携带的消息版本低于内存存储的消息版本，说明该消息是乱序消息，无需更新数据库，直接删除即可。如果消息中携带的消息版本等于内存存储的消息版本，说明该消息是重复消息，同样无需更新数据库，直接删除。

该实施例提供了一种去锁化的分布式版本管理方式，通过在分布式架构下引入消息队列，使得可以串行消费消息队列中的消息，避免了高并发情况下，由于锁竞争带来的资源消耗。同时，该实施例也是一种多消息版本合并的版本管理方式，实现了对来自不同业务节点的消息所携带的消息版本的统一管理，避免了消息消费乱序、重复的问题。另外，该版本管理方式与数据库解耦，实现了一次性访问数据库(每次处理消息，最多对数据库进行一次操作)，最大程度的降低了读写操作对数据库压力，相比常规锁机制能够提速一倍以上。

图4是根据本发明实施例的分布式版本管理方法的系统架构示意图。如图4所示，本发明实施例的分布式版本管理方法，由分布式版本管理系统实现，该分布式版本管理系统包括消息中间件和分布式版本管理装置。其中，消息中间件对接不同的业务子流程的消息数据流。下面对消息中间件和分布式版本管理装置所实现的功能进行具体说明。

消息中间件，用于接收多个业务节点执行各自的业务子流程所生成的消息，根据消息的主键和设定的哈希函数，将消息分发至对应的消息队列。

实施例中，哈希函数可用公式1表示，用于将主键与N倍的消息队列的数量进行取余运算。优选地，N的取值为1。

Index＝(PK)％Num 公式1

式中，Index为消息需要分发到的消息队列的编号；PK为消息的主键；Num为消息队列的数量的N倍，其中N为正整数；％表示取余运算。

进一步地，消息中间件基于Kafka实现，通过申请多个partition(分区，即一个消息队列)，将数据按主键分发到不同的分区上，以保障相同的主键发送到同一个分区。后续在消费消息时，只需串行化处理消息即可，无需全局锁定。

分布式版本管理装置，用于订阅单个的消息队列，当从消息队列获取到已订阅的消息时，根据消息中携带的节点标识，从内存存储的统一版本信息中截取对应的消息版本，之后将消息中携带的消息版本和截取的消息版本进行比对，在确定消息需要更新时(即携带的消息版本高于截取的消息版本)，再更新统一版本信息，将消息一次性写入数据库。

实施例中，消息版本可以是版本号、消息的状态信息等。可以理解的是，本实施例除支持事务型数据库，比如图4中的ES和MySQL之外，还支持OLAP型数据库和NOSQL数据库。其中，OLAP为联机分析处理，英文全称为Online Analytical Processing。OLAP型数据库，比如ClickHouse。NOSQL数据库泛指非关系型的数据库，比如Redis、HBas e。

图5是根据本发明实施例的分布式版本管理方法的主要流程示意图。如图5所示，本发明实施例的分布式版本管理方法，主要包括如下步骤：

步骤S501：从消息队列中获取消息。分布式版本管理装置的服务作为消费者，消费一个或者多个消息队列中的消息，具有相同主键的消息被同一服务消费。该消息包括主键、节点标识和局部消息版本。其中，主键用于唯一标识该消息，节点标识是生成该消息的业务节点的唯一标识，局部消息版本可以是消息的状态信息。

步骤S502：根据设定的关联关系，查找主键对应的统一版本信息，如果查找失败，则执行步骤S503；如果查找成功，则执行步骤S504。其中，关联关系用于记录主键和统一版本信息之间的对应关系。

步骤S503：根据消息中的节点标识和局部消息版本，生成统一版本信息，将统一版本信息存储到内存，执行步骤S501。如果未查找到主键对应的统一版本信息，说明是首次从消息队列中获取到具有该主键的消息，需要生成业务节点对应的统一版本信息。

实施例中，统一版本信息包括完成同一业务的各业务节点的消息所对应的版本字段。各版本字段可以是十进制的字符串，也可以是二进制的字符串。各版本字段的先后顺序也可以自定义设置。

以版本字段为十进制的字符串为例，在生成统一版本信息时，可以直接将局部消息版本填充到节点标识对应的版本字段，剩余的版本字段填充为0，即可得到统一版本信息。

假设业务节点1、业务节点2和业务节点3共同完成一个订单，在生成统一版本信息时，业务节点1的消息版本占用第1位，业务节点2的消息版本占用第2位，业务节点3的消息版本占用第3位。如果步骤S501中消息的节点标识为业务节点1，局部消息版本为状态1，则统一版本信息为100。

以版本字段为设定步长的二进制数值为例，在生成统一版本信息时，需先根据步长，将局部消息版本转换为对应的二进制数值，之后将二进制数值填充到节点标识对应的版本字段，剩余的版本字段填充为0，即可得到统一版本信息。

比如，步长设置为4，代表一个版本字段占4位，可表示16个状态。仍旧假设业务节点1、业务节点2和业务节点3共同完成一个订单，在生成统一版本信息时，业务节点1的消息版本占用前4位，业务节点2的消息版本占用中间4位，业务节点3的消息版本占用后4位。如果步骤S501中消息的节点标识为业务节点1，局部消息版本为状态1，则对应的二进制数值为0001，统一版本信息为000100000000。

在一可选的实施例中，各版本字段之间可以用分隔符，比如空格、短划线等隔开。另外，统一版本信息中还可以增加一个暂留字段，用于根据业务需求添加其他需要的信息。

步骤S504：根据节点标识，从内存存储的统一版本信息中截取与节点标识对应的版本字段，得到全局消息版本。如果查找到主键对应的统一版本信息，则从查找到的统一版本信息中，截取与节点标识对应的版本字段，得到全局消息版本。

以版本字段为设定步长的二进制数值为例，在截取与节点标识对应的版本字段时，可以先根据节点标识和步长，确定消息对应的版本字段在统一版本信息中占据的位置；之后使用位运算，从统一版本信息中截取该位置的二进制数值，将截取的二进制数值作为全局消息版本。

实施例中，在从统一版本信息中截取该位置的二进制数值时，可以先生成一个二进制字符串，该二进制字符串的位数与统一版本信息的位数相同，且二进制字符串中与该位置对应二进制位的取值为1，其余二进制位的取值为0，之后将统一版本信息与二进制字符串进行按位与运算，得到即可该位置的二进制数值。下面举例说明。

假设步骤S501中消息的节点标识为业务节点1，局部消息版本为状态5，查找到的统一版本信息为000100000000。则可以确定业务节点1占据统一版本信息的前4位，之后生成一个二进制字符串，该二进制字符串的前4位为1，后8位为0，即111100000000；将111100000000与000100000000进行按位与运算，得到0001，该值对应的十进制为1，即得到全局消息版本为状态1。

步骤S505：判断局部消息版本是否高于全局消息版本，如果局部消息版本高于全局消息版本，则执行步骤S506；如果局部消息版本低于或等于全局消息版本，则执行步骤S508。

步骤S506：更新统一版本信息，将消息写入数据库。如上例，由于局部消息版本为状态5，全局消息版本为状态1，可知局部消息版本高于全局消息版本，更新内存的统一版本信息，并将消息写入数据库。

在更新统一版本信息时，可以将局部消息版本转换为对应的二级制数值，将转换得到的二进制数值替换掉截取出的版本字段，即可完成内存的统一版本信息的更新。该例中，即用0101替换统一版本信息的前4位0001，得到更新后的统一版本信息010100000000。

步骤S507：将更新后的统一版本信息同步到远程数据库中，更新消息队列的偏移量，结束本流程。在消息写入数据库成功后，将更新后的统一版本信息同步到远程数据库(比如Redis)中，之后更新消息队列的偏移量(offset)。其中，offset用于标注消息的位置。offset更新后，说明消息消费成功，数据库中已经存储了最新的消息。

该步骤的处理能够保障整体数据的一致性，如果写入数据库、同步到远程数据库、更新offset中任意处理过程发生异常，都可以保证事件不丢失。后续可以通过重试的方式重新消费，保障了服务的高可用和数据的一致性、安全性。

步骤S508：删除消息，结束本流程。如果步骤S501中消息的节点标识为业务节点1，局部消息版本为状态5，步骤S504截取的该业务节点对应的全局消息版本也为状态5，可知局部消息版本等于全局消息版本，说明获取的消息是重复消息，直接删除。

如果步骤S501中消息的节点标识为业务节点1，局部消息版本为状态5，步骤S504截取的该业务节点对应的全局消息版本为状态6，可知局部消息版本低于全局消息版本，说明获取的消息是乱序消息，直接删除。

该实施例使用二进制数值构建统一版本信息，使得可以通过位运算实现版本管理，后续无需关注数据库的数据写入，无需与数据库进行多消息版本对比，保证了整体消息版本的顺序性，实现了对多个业务节点所生成消息的消息版本的统一管理。同时，可以通过拉取消息队列的数据实现批量处理，一次性批写入，进一步提高服务性能。

另外，上述实施例中，不管获取到多少条重复消息，均可以用同样的处理方式，得到同样的处理结果，保证了整体数据的幂等性；而且只有在将消息写入数据库并同步到远程数据库成功后，才触发偏移量的更新，保证了整体数据的事务性。其中，事务性是指事务所包含的操作，要么全部成功，要么全部失败。

图6是根据本发明实施例的分布式版本管理方法中统一版本信息的更新原理示意图。如图6所示，服务1订阅了消息队列1和消息队列2中的消息，服务2订阅了消息队列3中的消息。status1表示消息来自于业务节点1(比如下单支付节点)，status2表示消息来自于业务节点2(比如生产节点)。消息版本通过状态信息表示。

以服务1从消息队列1中获取到来自于业务节点1的消息为例，消息中携带的消息版本为状态1，由于此时是首次从消息队列1中获取具有该主键的消息，内存并未存储该业务节点的统一版本信息，则根据状态1生成该业务节点的消息对应的统一版本信息。

此时，统一版本信息为0001-0000-0000-0000。其中，该统一版本信息的前4位为业务节点1对应的版本字段，第5-8位为业务节点2对应的版本字段，第9-12位为业务节点3对应的版本字段，最后4位为暂存位。之后将该信息写入ES，将统一版本信息同步到Redis，更新消息队列1的offset。

如果新来一条来自于业务节点1的消息，即服务1从消息队列1中获取到来自于业务节点1的消息，消息中携带的消息版本为状态5，根据主键可以获取到此时的统一版本信息0001-0000-0000-0000，经消息版本比对后，消息中携带的消息版本高于内存的消息版本，则更新统一版本信息为0101-0000-0000-0000。之后将该信息写入ES，将更新的统一版本信息同步到Redis，更新消息队列1的offset。

接着服务1从消息队列1中获取到来自于业务节点2的消息，消息中携带的消息版本为状态2，根据主键可以获取到此时的统一版本信息0101-0000-0000-0000，经消息版本比对后，消息中携带的消息版本高于内存的消息版本，则更新统一版本信息为0101-0010-0000-0000。之后将该信息写入ES，将更新的统一版本信息同步到Redis，更新消息队列1的offset。

之后服务1从消息队列1中获取到来自于业务节点1的消息，消息中携带的消息版本为状态4，根据主键可以获取到此时的统一版本信息0101-0010-0000-0000，经消息版本比对后，消息中携带的消息版本低于内存的消息版本，说明该消息是乱序的，直接丢弃，内存的统一版本信息仍旧为0101-0010-0000-0000。

下面结合具体业务场景，对本发明实施例的统一版本信息的更新过程进行进一步说明。

以订单业务为例，其宽表数据包括订单数据字段、生产数据字段和配送数据字段。各数据字段的主键为订单号，且均为100。分布式版本管理装置按照消息队列中消息的存储顺序，依次消费各消息，并生成对应的统一版本信息。表1为顺序性处理各消息后所得到的统一版本信息。其中，orderStatus为订单状态，wmsStatus为生产状态，tmsSt atus为配送状态。

表1统一版本信息示例

由表1可知，分布式版本管理装置从消息队列中获取的消息，存在乱序、重复、订单取消等场景。对于订单取消场景，在接收到订单数据时，如果其携带的局部消息版本为状态10，说明订单取消，可直接将各业务节点对应的版本字段设置为全1，后续如果再接收到该主键的消息，统一版本信息将不再变化。

图7是根据本发明实施例的分布式版本管理装置的主要模块的示意图。如图7所示，本发明实施例的分布式版本管理装置700，主要包括：

消息获取模块701，用于从消息队列中获取消息。当前业务节点作为消息的生产者，在执行其业务子流程时会生成消息，该消息中可以包括当前业务节点的节点标识和局部消息版本。消息生成后，会被发送到消息中间件，由消息中间件将其存储到消息队列。

分布式版本管理装置作为消息的消费者，可以基于生产消费者模式或者发布订阅模式，从消息队列中获取消息。以发布订阅模式为例，分布式版本管理装置向消息中间件订阅其感兴趣的消息，再由消息中间件将这些消息发送至分布式版本管理装置的消息获取模块。

版本截取模块702，用于根据所述节点标识，从内存存储的统一版本信息中截取与所述节点标识对应的版本字段，得到全局消息版本；其中，所述统一版本信息包括多个业务节点的消息对应的版本字段，且所述多个业务节点用于完成同一业务。

统一版本信息存储在内存，包括多个业务节点的消息对应的版本字段，且多个业务节点用于完成同一业务。分布式版本管理装置获取到消息后，根据消息携带的节点标识，从统一版本信息中截取对应的版本字段，即可得到全局消息版本。

比较处理模块703，用于将所述局部消息版本与所述全局消息版本进行比较，如果所述局部消息版本高于所述全局消息版本，则更新所述统一版本信息，将所述消息写入数据库；如果所述局部消息版本低于或等于所述全局消息版本，则删除所述消息。

消息中携带的消息版本与内存存储的消息版本的版本高低，如果消息中携带的消息版本高于内存存储的消息版本，说明消息需要更新，则更新内存的统一版本信息，之后将该消息写入数据库。

如果消息中携带的消息版本低于内存存储的消息版本，说明该消息是乱序消息，无需更新数据库，直接删除即可。如果消息中携带的消息版本等于内存存储的消息版本，说明该消息是重复消息，同样无需更新数据库，直接删除。

另外，本发明实施例的分布式版本管理装置700还可以包括：查找处理模块和更新同步模块(图7中未示出)。其中，查找处理模块，用于根据设定的关联关系，查找所述主键对应的统一版本信息，确定查找失败；其中，所述关联关系用于记录所述主键和所述统一版本信息之间的对应关系；以及根据所述节点标识和所述局部消息版本，生成所述统一版本信息，将所述统一版本信息存储到内存。更新同步模块，用于将更新后的所述统一版本信息同步到远程数据库中，更新所述消息队列的偏移量。

从以上描述可以看出，通过统一版本信息记录多个业务节点所生成消息的消息版本，在获取到当前业务节点生成的消息时，先将该消息携带的消息版本与统一版本信息中记录的消息版本进行对比，根据对比结果确定需要更新时，再将消息写入数据库，实现了对多个业务节点的消息版本的去锁化、统一管理，避免了乱序、重复的消费消息，同时实现了一次性访问数据库，最大程度的降低了读写操作对数据库压力。

图8示出了可以应用本发明实施例的分布式版本管理方法或分布式版本管理装置的示例性系统架构800。

如图8所示，系统架构800可以包括消息中间件801、网络802和服务器803。网络802用以在消息中间件801和服务器803之间提供通信链路的介质。网络802可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

消息中间件801可以是提供各种服务的服务器，例如将生产者生成的消息，按照主键分发到不同的消息队列的代理服务器。

服务器803可以是提供各种服务的服务器，例如订阅消息中间件801的消息队列，对消息进行处理的后台管理服务器。后台管理服务器可以从统一版本信息中获取全局消息版本，将消息携带的局部消息版本与全局消息版本进行比对，根据比对结果进行不同处理。

需要说明的是，本申请实施例所提供的分布式版本管理方法一般由服务器803执行，相应地，分布式版本管理装置一般设置于服务器803中。

应该理解，图8中的消息中间件、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的消息中间件、网络和服务器。

根据本发明的实施例，本发明还提供了一种电子设备和一种计算机可读介质。

本发明的电子设备包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现本发明实施例的一种分布式版本管理方法。

本发明的计算机可读介质，其上存储有计算机程序，所述程序被处理器执行时实现本发明实施例的一种分布式版本管理方法。

下面参考图9，其示出了适用于来实现本发明实施例的电子设备的计算机系统900的结构示意图。图9示出的电子设备仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图9所示，计算机系统900包括中央处理单元(CPU)901，其可以根据存储在只读存储器(ROM)902中的程序或者从存储部分908加载到随机访问存储器(RAM)903中的程序而执行各种适当的动作和处理。在RAM 903中，还存储有计算机系统900操作所需的各种程序和数据。CPU 901、ROM 902以及RAM 903通过总线904彼此相连。输入/输出(I/O)接口905也连接至总线904。

以下部件连接至I/O接口905：包括键盘、鼠标等的输入部分906；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分907；包括硬盘等的存储部分908；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分909。通信部分909经由诸如因特网的网络执行通信处理。驱动器910也根据需要连接至I/O接口905。可拆卸介质911，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器910上，以便于从其上读出的计算机程序根据需要被安装入存储部分908。

特别地，根据本发明公开的实施例，上文主要步骤图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行主要步骤图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分909从网络上被下载和安装，和/或从可拆卸介质911被安装。在该计算机程序被中央处理单元(CPU)901执行时，执行本发明的系统中限定的上述功能。

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

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

描述于本发明实施例中所涉及到的模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的模块也可以设置在处理器中，例如，可以描述为：一种处理器包括消息获取模块、版本截取模块和比较处理模块。其中，这些模块的名称在某种情况下并不构成对该模块本身的限定，例如，消息获取模块还可以被描述为“从消息队列中获取消息的模块”。

作为另一方面，本发明还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该设备包括：从消息队列中获取消息；其中，所述消息是当前业务节点执行业务子流程生成的，包括所述当前业务节点的节点标识和局部消息版本；根据所述节点标识，从内存存储的统一版本信息中截取与所述节点标识对应的版本字段，得到全局消息版本；其中，所述统一版本信息包括多个业务节点的消息对应的版本字段，且所述多个业务节点用于完成同一业务；将所述局部消息版本与所述全局消息版本进行比较，如果所述局部消息版本高于所述全局消息版本，则更新所述统一版本信息，将所述消息写入数据库；如果所述局部消息版本低于或等于所述全局消息版本，则删除所述消息。

根据本发明实施例的技术方案，通过统一版本信息记录多个业务节点所生成消息的消息版本，在获取到当前业务节点生成的消息时，先将该消息携带的消息版本与统一版本信息中记录的消息版本进行对比，根据对比结果确定需要更新时，再将消息写入数据库，实现了对多个业务节点的消息版本的去锁化、统一管理，避免了乱序、重复的消费消息，同时实现了一次性访问数据库，最大程度的降低了读写操作对数据库压力。

上述产品可执行本发明实施例所提供的方法，具备执行方法相应的功能模块和有益效果。未在本实施例中详尽描述的技术细节，可参见本发明实施例所提供的方法。

上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。