CN117370457B - 一种多线程数据实时同步方法、设备及介质 - Google Patents

Abstract

本申请公开了一种多线程数据实时同步方法、设备及介质，方法包括：通过生产者确定业务信息对应的消息数据，发送到数据同步服务组件，获得对应的生产者消息流水数据，并发布消息定时发送线程的监听事件，通过信号量控制线程数量方式唤醒消息定时发送线程，将消息数据发送到对应消息同步主题的消息队列中，确定消费者订阅主题，拉取消息队列中的消息数据，对消息数据进行消费，并保存消费者消息流水数据。实现多线程数据实时同步，并实现在单个实例执行相关操作，防止出现并发问题而导致的数据不一致，从而保证数据同步的正确性，并且添加消息定时发送线程，对未发送的消息进行补偿发送，以确保数据操作的原子性以及顺序一致性。

Description

一种多线程数据实时同步方法、设备及介质

技术领域

本申请涉及软件***开发中的微服务领域，具体涉及一种多线程数据实时同步方法、设备及介质。

背景技术

在当前软件***开发中的微服务领域中，存在的微服务架构，将应用程序拆分为一组小型的服务，并且每个服务都专注于完成一个特定的业务功能，并通过轻量级的通信机制相互配合，其中不同的服务对应着不同的业务数据库。

随着业务变的越来越复杂，业务数据量也就越来越多，需要多个数据中心或多个节点之间来进行数据的存储和处理，因此就需要一种高可用且高可靠的数据同步服务，以确保多个节点之间的数据保持同步。

数据同步服务是指将数据从一个***复制到另一个***的过程，在这个过程中的关键要点是保证数据操作的原子性以及顺序一致性，而当前软件***开发中的微服务领域中，难以实现操作的原子性以及顺序一致性。

发明内容

为了解决上述问题，本申请提出了一种多线程数据实时同步方法，包括：

通过生产者确定业务信息对应的消息数据，将所述消息数据发送到数据同步服务组件；

通过所述数据同步服务组件获得所述消息数据对应的生产者消息流水数据，并发布消息定时发送线程的监听事件；

启动消息定时发送线程的***，通过信号量控制线程数量方式唤醒消息定时发送线程，以定时拉取所述生产者消息流水数据；

遍历所述生产者消息流水数据，基于不同的数据类型，将所述消息数据从所述数据同步组件发送到对应消息同步主题的消息队列中，并基于所述消息同步主题更新所述生产者消息流水数据；

确定消费者订阅所述消息同步主题，通过所述消费者拉取所述消息同步主题的消息队列中的消息数据，根据所述生产者消息流水数据中的消息发送顺序，对所述消息数据进行消费，并保存消费者消息流水数据。

另一方面，本申请还提出一种多线程数据实时同步设备，包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如：上述示例所述的多线程数据实时同步方法。

另一方面，本申请还提出了一种非易失性计算机存储介质，存储有计算机可执行指令，所述计算机可执行指令设置为：上述示例所述的多线程数据实时同步方法。

通过本申请提出一种多线程数据实时同步方法能够带来如下有益效果：

基于分布式消息队列中间件***来实现多线程数据实时同步，能够实现在微服务***中，通过分布式锁限制单个实例执行相关操作，防止出现并发问题而导致的数据不一致，同时也控制节点对资源的访问顺序，从而保证数据同步的正确性。

并且添加消息定时发送线程，当数据发送出现异常时，消息定时发送线程能对未发送的消息进行补偿发送，直到消息发送成功，最大限度保证了数据同步的可靠性，并保证了数据操作的原子性，以分布式锁的方式进行排他操作，避免出现两个应用服务同时补偿相同数据的错误情况，以保证数据同步的高可用性。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例中一种多线程数据实时同步方法的流程示意图；

图2为本申请实施例中一种多线程数据实时同步方法的生产者流程示意图；

图3为本申请实施例中一种多线程数据实时同步方法的消费者流程示意图；

图4为本申请实施例中一种多线程数据实时同步设备的示意图。

具体实施方式

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

以下结合附图，详细说明本申请各实施例提供的技术方案。

如图1所示，本申请实施例提供一种多线程数据实时同步方法，包括：

S101：通过生产者确定业务信息对应的消息数据，将所述消息数据发送到数据同步服务组件。

在微服务架构中，每个微服务都有自己业务逻辑，并完成自己特定的业务功能，因此在微服务对应的业务中，每个业务都有自己的数据存储，当微服务之间需要共享数据时，通过数据同步的技术将业务之间的数据进行共享和同步。本申请实施例中所提供的方法是基于开源的分布式消息队列中间件***(例如RocketMQ***、Kafka***、Rabbi tMQ***等，在说明书中使用例如RocketMQ***为例来对申请提供的方法来对说明书进行解释)来实现的，包括生产者、消费者、主题、主题内包含的消息队列、消息服务器等组件。

具体地，如图2所示，在业务组件中，根据业务确定对应的业务信息(例如支付业务的业务信息有支付账户、支付金额、支付时间、支付结果等信息)，并根据业务信息确定需要执行业务操作的消息数据。

进一步地，通过生产者构建消息数据，并基于该消息数据构建消息数据对象，以在后续的过程中方便对消息数据的操作，利用消息数据对象，将消息数据发送到数据同步服务组件中。

S102：通过所述数据同步服务组件获得所述消息数据对应的生产者消息流水数据，并发布消息定时发送线程的监听事件。

如图2所示，在生产者将消息数据发送到数据同步服务组件过程中，获得生产者消息流水数据，并将生产者消息流水数据保存到数据库内对应的生产者流水表中。

其中，生产者消息流水数据(在一些场景下，也可以如图2所示，将其称作生产者流水记录)包括消息数据的唯一标识、发送时间、消息数据的内容、数据类型、发送状态、发送记录、目标主题等内容，并且保证在同一事务下，保存一条消息流水数据。

同时，在数据同步服务组件中发布消息定时发送线程的监听事件，以监听数据同步过程中发生的异常或失败，从而导致消息发送的暂时中断，通过消息定时发送线程对数据进行修复或补偿，将未发送的消息进行补偿发送，以确保数据的一致性、准确性以及数据操作的原子性。

S103：启动消息定时发送线程的***，通过信号量控制线程数量方式唤醒消息定时发送线程，以定时拉取所述生产者消息流水数据。

启动消息定时发送线程的***，调用ScheduledThreadPoolExecutor类，初始化消息定时发送线程，通过信号量方式唤醒消息定时发送线程，其中，ScheduledThreadPoolExecutor类用于执行定时任务，消息定时发送线程是基于ScheduledThreadPoolExecutor类设计的定时补偿任务,包含处理发送消息顺序、更新消息流水记录状态、唤醒重试等功能。

具体地，通过信号量来控制线程数量，创建一个信号量对象，将其初始值设置为0，此时在消息定时发送线程中，线程为等待状态；当需要唤醒消息定时发送线程时，比如当有新消息需要发送时，调用相关函数释放信号量，信号量的值大于0时，消息定时发送线程被唤醒，执行消息定时补偿任务。

进一步地，如图2所示，自定义设置时间间隔，并定时拉取在时间间隔内生产者消息流水数据中消息数据的发送频率，以及消息数据发送的记录数量(在一些场景下，也可以如图2所示，将其称作定时拉取数据同步流水数据)，并扫描数据库内生产者流水表中尚未发送的消息数据，将未发送的消息数据进行补偿发送，直到最终发送成功，以分布式锁的方式进行排他操作，避免出现两个应用服务同时补偿相同数据的错误情况，以保证数据同步的高可用性以及数据操作的原子性。

S104：遍历所述生产者消息流水数据，基于不同的数据类型，将所述消息数据从所述数据同步组件发送到对应消息同步主题的消息队列中，并基于所述消息同步主题更新所述生产者消息流水数据。

具体地，遍历生产者消息流水数据，获得发送到数据同步组件的消息数据的内容和数据类型，根据不同的数据类型，确定消息数据发送的指定主题，根据指定主题获得该主题的消息队列，将消息数据从数据同步组件发送到对应消息同步主题的消息队列中，此时，消息数据已被发送到消息队列中，更新生产者消息流水数据中消息数据的发送状态和发送记录，并将数据库内生产者流水表内的数据也进行更新。

其中，在处理消息数据的发送任务时，基于分布式锁，限制在任意时刻只有一个实例执行发送任务，当该实例的发送任务完成后，释放分布式锁，使其他实例能够获取锁并执行相应的任务，以保证消息数据同步时的全局顺序性。

进一步地，在将消息数据从数据同步组件发送到对应消息同步主题的消息队列中后，将消息数据已发送的消息发送到所述对应的消息队列，使消息队列确定已收到数据。

更进一步地，当消息数据未正常发送或消息定时发送线程出现异常时，自定义设置时间，在这个时间段内读取生产者消息流水数据中的的记录数量，并扫描生产者流水表中尚未发送的消息数据，对未发送的消息数据进行补偿发送，重新发送到所述对应的消息队列中，直到最终发送成功；当消息定时发送线程出现异常，但是经过扫描生产者流水表后，没有发现未发送的消息数据时，将消息定时发送线程直接退出本次任务，等待下次唤醒是进行重试。

S105：确定消费者订阅所述消息同步主题，通过所述消费者拉取所述消息同步主题的消息队列中的消息数据，根据所述生产者消息流水数据中的消息发送顺序，对所述消息数据进行消费，并保存消费者消息流水数据。

如图3所示，通过消费者来订阅消息同步主题，从而确定该订阅主题内的消息队列，从消息队列内拉取同步消息数据到数据同步组件，并在数据同步组件中进行消费数据前的处理。

具体地，定义RocketMq消费者***实现类，以监听是否有新消息到达，并根据消息类型查询对应的服务实现类，调用消息消费者基本抽象类，根据所述不同的数据类型，查询对应的服务器实现类，以实现对所述消息数据的消费操作。

其中，消息消费者基本抽象类的成员变量或方法包括应用程序上下文对象、业务服务对象映射集合、消息入口处理定义、消费重试监听实现等，业务服务对象映射集合内定义了消息数据的数据类型以及消息消费者基类接口的实现类列表，其中消息消费者基类接口包括三个接口方法，分别是doHandle方法、handleMessageType方法、handleConsumerClass方法，doHandle方法是对消息数据进行实际业务处理的模板方法，通过其子类来提供具体的实现逻辑，handleMessageType方法返回数据类型，handleConsumerClass返回关联的RocketMq消费者***实现类。

根据业务服务对象映射集合内的数据类型，从应用程序上下文对象中获取业务服务对象并保存到业务服务对象映射集合中，并且通过消息消费者基本抽象类提供的缺省的消息处理入口方法，调用消息消费入口服务类对象的消息处理方法，或者也可以根据实际需求，在自定义的消费者子类中重写该方法，实现相应的业务逻辑。

消费重试监听实现功能包括：实现RocketMq消费者***实现类接口的onMessage方法，设置对消息数据进行消费的重试次数，并且当达到最大重试次数时进行异常处理。

进一步地，获取数据库中的消费流水表，调用消息消费入口服务类，根据消费者消息流水数据的唯一标识，判断当前消息数据是否存在于消费流水表中，其中消费流水表中包括消费者消息流水数据的唯一标识、消息数据的唯一标识、消费者的唯一标识、消费记录、消费状态等信息。

若当前消息数据不存在，调用具体消费者业务类，实现消息消费者基类接口中的三个接口方法，返回关联的RocketMq消费者***实现类，并根据不同的数据类型，调用具体消费者业务类，处理对应的业务逻辑，之后判断当前业务数据库路由键与数据同步服务的配置值是否匹配，当确定匹配时，执行对当前消息数据的消费操作，并将当前消息数据存入到数据库中的业务表中，当确定不匹配时，将不匹配的消息保存到数据库中的消费流水表中。

若当前消息数据存在，表示该消息数据已经进行过消费操作并将消费记录保存到消费流水表中了，之后将当前消息数据已被正常消费的消息提交给消息队列，防止消息数据的重复消费，以保证消息同步的幂等性。

如图4所示，本申请实施例还提出了多线程数据实时同步设备，包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如：上述示例所述的多线程数据实时同步方法。

本申请实施例还提供了一种非易失性计算机存储介质，存储有计算机可执行指令，所述计算机可执行指令设置为：上述示例所述的多线程数据实时同步方法。

本申请中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于设备和介质实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本申请实施例提供的设备和介质与方法是一一对应的，因此，设备和介质也具有与其对应的方法类似的有益技术效果，由于上面已经对方法的有益技术效果进行了详细说明，因此，这里不再赘述设备和介质的有益技术效果。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (4)

1.一种多线程数据实时同步方法，其特征在于，包括：

通过生产者确定业务信息对应的消息数据，将所述消息数据发送到数据同步服务组件；

通过所述数据同步服务组件获得所述消息数据对应的生产者消息流水数据，并发布消息定时发送线程的监听事件；

启动消息定时发送线程的***，通过信号量控制线程数量方式唤醒消息定时发送线程，以定时拉取所述生产者消息流水数据；

遍历所述生产者消息流水数据，基于不同的数据类型，将所述消息数据从所述数据同步组件发送到对应消息同步主题的消息队列中，并基于所述消息同步主题更新所述生产者消息流水数据；

所述基于不同的数据类型，将所述消息数据从所述数据同步组件发送到对应消息同步主题的消息队列中，并基于所述消息同步主题更新所述生产者消息流水数据，具体包括：

基于分布式锁控制单个实例执行发送任务，根据不同的数据类型将所述消息数据发送到对应消息同步主题的消息队列中；

基于所述消息同步主题更新所述生产者消息流水数据中的消息数据的发送状态，并将所述消息数据已发送的消息发送到对应的消息队列；

确定消费者订阅所述消息同步主题，通过所述消费者拉取所述消息同步主题的消息队列中的消息数据，根据所述生产者消息流水数据中的消息发送顺序，对所述消息数据进行消费，并保存消费者消息流水数据；

所述通过所述消费者拉取所述消息同步主题的消息队列中的消息数据，根据所述生产者消息流水数据中的消息发送顺序，对所述消息数据进行消费，具体包括：

定义RocketMq消费者***实现类，调用消息消费者基本抽象类，根据所述不同的数据类型，查询对应的服务器实现类，以实现对所述消息数据的消费操作；

获取数据库中的消费流水表，调用消息消费入口服务类，判断当前消息数据在所述消费流水表中是否存在；

若当前消息数据不存在，调用具体消费者业务类，并判断当前主题对应的业务数据库路由键与数据同步服务的配置值是否匹配，当确定匹配时，执行对所述当前消息数据的消费操作，并将所述当前消息数据存入到数据库中的业务表中，当确定不匹配时，将所述不匹配的消息保存到数据库中的所述消费流水表中；

若当前消息数据存在，将所述当前消息数据已被正常消费的消息提交给所述消息队列；

所述调用消息消费者基本抽象类，根据所述不同的数据类型，查询对应的服务器实现类，具体包括：

确定所述消息消费者基本抽象类的方法包括应用程序上下文对象、业务服务对象映射集合、消息入口处理定义、消费重试监听实现；

根据所述业务服务对象映射集合内的所述数据类型，从所述应用程序上下文对象中获取业务服务对象并保存到所述业务服务对象映射集合中；

所述消息入口处理定义具体包括：调用消息消费入口服务类，自定义重写消息处理方法，以实现自定义的业务逻辑；

所述消费重试监听具体包括：设置对所述消息数据进行消费的重试次数，并且当达到最大重试次数时进行异常处理；

其中，业务服务对象映射集合内定义了消息数据的数据类型以及消息消费者基类接口的实现类列表，消息消费者基类接口包括三个接口方法；

所述方法还包括：

当所述消息数据未正常发送或所述消息定时发送线程异常时，将所述消息数据进行补偿，重新发送到所述对应的消息队列中；

当所述消息定时发送线程异常且没有待补偿数据时，所述消息定时发送线程会重新回到休眠状态，等待下次唤醒；

当所述消息定时发送线程异常时，自定义设置读取所述生产者消息流水数据中的记录数量以及读取时间间隔，扫描生产者流水表中尚未发送的消息数据，并进行补偿发送，重新发送到所述对应的消息队列中，直到最终发送成功。

2.根据权利要求1所述的方法，其特征在于，通过生产者将所述消息数据发送到数据同步服务组件，获得生产者消息流水数据，具体包括：

通过生产者生成所述消息数据，并将所述消息数据发送到数据同步服务组件中，获得生产者消息流水数据，将所述生产者消息流水数据保存到数据库内生产者流水表中；

确定同一事务保存一条消息流水数据，其中，所述消息流水数据为生产者消息流水数据，或，消费者消息流水数据。

3.一种多线程数据实时同步设备，其特征在于，包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如：权利要求1-2中任一项权利要求所述的多线程数据实时同步方法。

4.一种非易失性计算机存储介质，存储有计算机可执行指令，其特征在于，所述计算机可执行指令设置为：权利要求1-2中任一项权利要求所述的多线程数据实时同步方法。