CN116016555A - 一种消息同步方法、装置、设备及计算机存储介质 - Google Patents

Abstract

本申请实施例公开了一种消息同步方法、装置、设备及计算机存储介质，其中，所述方法包括：接收客户端发送的待处理消息；在同步所述待处理消息的同时，接收所述客户端发送的新的待处理消息，其中，所述同步包括将所述待处理消息复制至从节点；在预设时间段内，确定所述待处理消息成功复制至所述从节点的情况下，返回同步成功消息至所述客户端，其中，所述同步成功消息用于表征所述待处理消息同步成功。

Description

一种消息同步方法、装置、设备及计算机存储介质

技术领域

本申请实施例涉及互联网服务技术领域，涉及但不限于一种消息同步方法、装置、设备及计算机存储介质。

背景技术

现有技术中，RocketMQ是一款开源的分布式消息系统，基于高可用分布式集群技术，提供低延时的、高可靠的消息发布与订阅服务。在主节点(Master)同步消息到从节点(Slave)上的情况下，RocketMQ提供了两种方式：异步复制和同步双写。

异步复制方案，当Master返回确认(Ack)成功状态后，消息可能还没来得及同步至Slave，如果此时机器故障宕机，可能就会造成消息丢失，导致消费者消费不到该部分消息的问题。

同步双写方案，Master节点的消息处理线程需要等待消息被同步到Slave才能处理新的消息请求，存在性能方面比异步复制模式低，发送单个消息的往返(Round-Trip，RT)时间也会增高的问题。

发明内容

有鉴于此，本申请实施例为解决现有技术中存在的至少一个问题而提供一种消息同步方法、装置、设备及存储介质，至少解决了现有技术中异步复制方案存在的机器故障宕机，可能就会造成消息丢失，导致消费者消费不到该部分消息的问题和同步双写方案中性能方面比异步复制模式低，发送单个消息的往返时间也会增高的问题。

本申请实施例的技术方案是这样实现的：

第一方面，本申请实施例提供一种消息同步方法，所述方法包括：接收客户端发送的待处理消息；在同步所述待处理消息的同时，接收所述客户端发送的新的待处理消息，其中，所述同步包括将所述待处理消息复制至从节点；在预设时间段内，确定所述待处理消息成功复制至所述从节点的情况下，返回同步成功消息至所述客户端，其中，所述同步成功消息用于表征所述待处理消息同步成功。

第二方面，本申请实施例提供一种消息同步装置，所述装置包括：接收模块，用于接收客户端发送的待处理消息；处理模块，用于在同步所述待处理消息的同时，接收所述客户端发送的新的待处理消息，其中，所述同步包括将所述待处理消息复制至从节点；第一返回模块，用于预设时间段内，在确定所述待处理消息成功复制至所述从节点的情况下，返回同步成功消息至所述客户端，其中，所述同步成功消息用于表征所述待处理消息同步成功。

第三方面，本申请实施例提供一种电子设备，包括存储器和处理器，所述存储器存储有可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述方法。

第四方面，本申请实施例提供一种计算机存储介质，存储有可执行指令，用于引起处理器执行时，实现上述方法。

本申请实施例中，首先接收客户端发送的待处理消息，然后在同步所述待处理消息的同时，接收所述客户端发送的新的待处理消息，最后预设时间段内，在确定所述待处理消息成功复制至从节点的情况下，返回同步成功消息至所述客户端。这样，主节点在将待处理消息成功复制至从节点的情况下，返回同步成功消息，解决了现有技术中异步复制方案可能造成消息丢失的问题；在同步待处理消息的同时，接收客户端发送的新的待处理消息，实现了一种流水线的形式来处理主节点和从节点之间的消息复制，不再等待消息复制至从节点后再处理新请求，而是在获取新的待处理消息之前生成异步任务，由异步任务去执行消息的复制，异步执行完成后再去响应客户端确认，消息的处理流程会像流水一样，减少了线程的长时间等待，提高性能，解决了现有技术中同步双写方案中性能方面比异步复制模式低，发送单个消息的往返时间也会增高的问题。

附图说明

图1为本申请实施例提供的一种消息同步方法的流程示意图；

图2为本申请实施例提供的一种消息同步方法的流程示意图；

图3A为本申请实施例提供的同步双写和异步复制的消息处理流程示意图；

图3B为本申请实施例提供的一种消息同步方法的流程示意图；

图4A为本申请实施例提供的异步复制、同步双写和优化后的异步任务三种方式每秒处理的消息数量的示意图；

图4B为本申请实施例提供的异步复制、同步双写和优化后的异步任务三种方式延时指标的比对示意图；

图5为本申请实施例提供的消息同步装置的组成结构示意图；

图6为本申请实施例提供的电子设备的一种硬件实体示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对发明的具体技术方案做进一步详细描述。以下实施例用于说明本申请，但不用来限制本申请的范围。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。

在以下的描述中，所涉及的术语“第一\第二\第三”仅仅是是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。

应当理解，此处所描述的一些实施例仅仅用以解释本申请的技术方案，并不用于限定本申请的技术范围。

本申请实施例提供的一种消息同步方法，应用于主节点，如图1所示，该方法包括：

步骤S101、接收客户端发送的待处理消息；

随着互联网技术蓬勃发展，微服务架构思想的兴起，系统架构开始追求小型化、轻量化，原有的大型集中式的系统通常需要进行垂直拆分，孵化出颗粒更小的众多小型系统，因此对系统间松耦合的要求越来越高。通过引入消息中间件，服务之间可以通过可靠的异步调用，降低系统之间的耦合度，提高系统的可用性。举例来说，RocketMQ是一个队列模型的消息中间件，具有高性能、高可靠、高实时、分布式的特点。RocketMQ作为一款高性能消息中间件，为了提高消息消费的高可用性，避免消息转发器(Broker)发送单点故障引起存储在Broker上的消息无法及时消费，RocketMQ引入Broker的主备机制，每个Broker组都是主从结构，一个主节点可以对应多个从节点，但是一个从节点只能对应一个主节点，主节点与从节点的对应关系通过指定相同的brokerName，不同的brokerId来定义。

客户端可以是生产者，消费者需要从主节点或从节点上获取消息进行消费。这里，生产者消费者模式是一个多线程并发协作的模式，包含了两类线程，一种是生产者线程用于生产数据，另一种是消费者线程用于消费数据。这里，客户端即用于生产消息的生产者。待处理消息即客户端生产的消息。

在实施过程中，可以是主节点接收客户端发送的待处理消息。

步骤S102、在同步所述待处理消息的同时，接收所述客户端发送的新的待处理消息，其中，所述同步包括将所述待处理消息复制至从节点；

这里，由于消费者需要获取从节点的消息进行消费，所以需要主节点同步待处理消息至从节点，在一个主节点对应多个从节点的情况下，需要多个从节点复制主节点的待处理消息，以确保消费者可以从不同的从节点获取客户端发送的待处理消息。

在实施过程中，可以采用异步处理的方法在同步所述待处理消息的同时，接收所述客户端发送的新的待处理消息。即，生产者发送的待处理消息到达主节点后，不再等待该待处理消息复制到从节点后再处理新的待处理消息，而是生成一个异步任务去执行复制任务后返回，并马上处理新的待处理消息。

这样，不需要等从节点的消息同步成功确认即可对下一个消息请求进行处理，实现了一种流水线的形式来处理主节点和从节点之间的消息复制。这里，在一个登录操作过程中分别执行多个任务，这个过程可以称为异步处理。异步处理不会造成线程阻塞，相当于各自处理各自的任务。异步处理在调用后不能马上得到结果，需要在后期查询或接收事件获得执行结果，可以在等待时做其它处理。

步骤S103、在预设时间段内，确定所述待处理消息成功复制至从节点的情况下，返回同步成功消息至所述客户端，其中，所述同步成功消息用于表征所述待处理消息同步成功。

在实施过程中，存在多个从节点的情况下，需要确定待处理消息已完成成功复制至多个从节点，再返回同步成功消息至客户端。

本申请实施例中，首先接收客户端发送的待处理消息，然后在同步所述待处理消息的同时，接收所述客户端发送的新的待处理消息，最后预设时间段内，在确定所述待处理消息成功复制至从节点的情况下，返回同步成功消息至所述客户端。这样，主节点在将待处理消息成功复制至从节点的情况下，返回同步成功消息，解决了现有技术中异步复制方案可能造成消息丢失的问题；在同步待处理消息的同时，接收客户端发送的新的待处理消息，实现了一种流水线的形式来处理主节点和从节点之间的消息复制，不再等待消息复制至从节点后再处理新请求，而是在获取新的待处理消息之前生成异步任务，由异步任务去执行消息的复制，异步执行完成后再去响应客户端确认，消息的处理流程会像流水一样，减少了线程的长时间等待，提高性能，解决了现有技术中同步双写方案中性能方面比异步复制模式低，发送单个消息的往返时间也会增高的问题。

本申请实施例提供的一种消息同步方法，应用于主节点，该方法包括：

步骤S110、接收客户端发送的待处理消息；

步骤S111、在将所述待处理消息保存至所述主节点的磁盘和将所述待处理消息复制至从节点的同时，接收所述客户端发送的新的待处理消息；

在实施过程中，由于主节点需要将待处理消息保存至磁盘，以确保断电或者宕机的情况下，待处理消息不会丢失，所以主节点需要生成两个任务，同时处理两件事情：将所述待处理消息保存至所述主节点的磁盘和将所述待处理消息复制至从节点。在处理上述两件事情的同时，主节点接收所述客户端发送的新的待处理消息，再生成两个新的任务，处理新的待处理消息。

步骤S112、在预设时间段内，确定所述待处理消息成功保存至所述主节点的磁盘和所述待处理消息成功复制至从节点的情况下，返回同步成功消息至所述客户端；

步骤S113、在所述预设时间段内，确定所述待处理消息未成功保存至所述主节点的磁盘，和/或所述待处理消息未成功复制至所述从节点的情况下，向所述客户端返回同步失败消息，其中，所述同步失败消息用于表征所述待处理消息同步失败；

在实施过程中，存在以下两种未成功处理待处理消息的情况：情况一、待处理消息未成功保存至主节点的磁盘；情况二、待处理消息未成功复制至所述从节点。可以根据实际需求设置预设时间段，如果在预设时间段内以上至少一种情况发送，则向客户端返回同步失败消息。

步骤S114、在所述待处理消息同步失败的情况下，重新获取所述待处理消息。

在所述待处理消息同步失败的情况下，即，待处理消息未成功保存至主节点的磁盘和/或待处理消息未成功复制至所述从节点，会影响消费者从主节点或从节点获取待处理消息进行消息，所以需要重新获取待处理消息，进行待处理消息的同步，即执行上述步骤S111。

本申请实施例中，首先在将所述待处理消息保存至所述主节点的磁盘和将所述待处理消息复制至从节点的同时，接收所述客户端发送的新的待处理消息，在预设时间段内，确定所述待处理消息成功保存至所述主节点的磁盘和所述待处理消息成功复制至从节点的情况下，返回同步成功消息至所述客户端。这样，返回同步成功消息，可以确保消费者正常从主节点或从节点获取待处理消息进行消费。

本申请实施例中，在所述待处理消息同步失败的情况下，重新获取所述待处理消息。这样，待处理消息未成功保存至主节点的磁盘和/或待处理消息未成功复制至所述从节点，会影响消费者从主节点或从节点获取待处理消息进行消息，所以需要重新获取待处理消息，进行待处理消息的同步。

上述步骤S111中的“将所述待处理消息保存至所述主节点的磁盘”可以通过以下步骤实现：

将所述待处理消息写入所述主节点的缓存；

将所述缓存中的待处理消息写入所述主节点的消息存储文件。

上述步骤S111中的“将所述待处理消息复制至从节点”可以通过以下步骤实现：

提交同步请求到同步复制服务，其中，所述同步请求包括所述待处理消息；

在所述同步复制服务确定所述从节点完成复制所述待处理消息的情况下，确定将所述待处理消息复制至从节点。

本申请实施例提供的一种消息同步方法，应用于主节点，所述主节点包括业务处理线程，如图2所示，该方法包括：

步骤S201、所述业务处理线程利用通信模块接收所述客户端发送的待处理消息；

步骤S202、所述业务处理线程创建消息处理任务，同时接收所述客户端发送的新的待处理消息；

步骤S203、所述消息处理任务将所述待处理消息写入缓存；

步骤S204、所述业务处理线程创建消息同步任务和消息落盘任务；

步骤S205、所述消息落盘任务将所述缓存中的所述待处理消息保存至所述主节点的磁盘；

步骤S206、所述消息同步任务将所述待处理消息复制至所述从节点；

步骤S207、预设时间段内，在所述消息处理任务确定所述消息同步任务将所述待处理消息成功保存至所述主节点的磁盘，和所述消息落盘任务将所述待处理消息成功复制至从节点的情况下，所述消息处理任务返回同步成功消息至所述客户端。

本申请实施例中，采用了一种任务划分的机制，将每个消息处理的过程分为多个异步任务，其中，消息处理任务复制将消息存入缓存和返回确认消息、同步任务负责将消息复制至从节点、消息落盘任务负责消息落盘。

具有以下有益技术效果：

(1)高可用性：本申请实施例采用消息同步的异步任务线程会等待消息在主节点和从节点上都写入成功后才会向客户端返回确认成功状态，服务可用性和数据可用性都非常高。解决了异步复制消息写入主节点之后就直接返回确认，如果复制线程未执行完主节点宕机了，可能会造成消息丢失，无法保证可靠性的问题。

(2)提升性能：本申请实施例使用异步任务处理额外的消息复制过程，使得对消息的处理流式化，大大提高了Broker的接收消息的处理能力。解决了同步双写会造成性能下降、中央处理器(Central Processing Unit，CPU)资源无法被充分使用的问题。

随着互联网技术蓬勃发展，微服务架构思想的兴起，系统架构开始追求小型化、轻量化，原有的大型集中式的系统通常需要进行垂直拆分，孵化出颗粒更小的众多小型系统，因此对系统间松耦合的要求越来越高。通过引入消息中间件，服务之间可以通过可靠的异步调用，降低系统之间的耦合度，提高系统的可用性。

RocketMQ是一个队列模型的消息中间件，具有高性能、高可靠、高实时、分布式的特点，是一个采用Java语言开发的分布式的消息系统。RocketMQ作为一款高性能消息中间件，为了提高消息消费的高可用性，避免消息转发器(Broker)发送单点故障引起存储在Broker上的消息无法及时消费，RocketMQ引入Broker的主备机制，每个Broker组都是主从(Master/Slave)结构，一个Master可以对应多个Slave，但是一个Slave只能对应一个Master，Master与Slave的对应关系通过指定相同的brokerName，不同的brokerId来定义，Broker为消息转发器，同时也负责一些控制和管理操作。

生产者发送的消息到达Master后，会进行数据同步到Slave，当Master宕机之后，消费者在获取更新消息之后会将连接到对应的Slave继续消费。在Master同步消息到Slave上，RocketMQ提供了两种方式。

图3A为本申请实施例提供的同步双写和异步复制的消息处理流程示意图，如图3A所示，同步双写和异步复制的消息处理包括以下步骤：

同步双写：

步骤S301、主节点接收生产者发送的消息；

步骤S302、主节点将消息成功落盘后，需要等待Slave节点复制成功(如果有多个Slave，成功复制一个就可以)；

步骤S303、在主节点确定消息成功落盘和从节点复制成功的情况下，返回确认成功状态到客户端。

异步复制：

步骤S301、主节点接收生产者发送的消息；

步骤S303、在主节点确定消息成功落盘后，返回确认成功状态到客户端；

无需等待消息从主节点复制至从节点，消息的复制由其他线程完成；

步骤S304、由其他线程完成消息从主节点复制至从节点。

在实施过程中，RocketMQ集群中主节点和从节点同步方式是通过Broker配置文件里的brokerRole参数进行设置的，其中SYNC_MASTER表示同步双写，ASYNC_MASTER表示异步复制。

异步复制方案存在的问题如下：

异步复制方案的消息复制由其他线程完成，并发性能高，消息实时性基本不受影响，但是可能会造成消息丢失，因为当主节点返回确认成功状态后，消息可能还没来得及同步至从节点，如果此时机器故障宕机了，可能就会造成消息丢失，导致消费者消费不到该部分消息。

同步双写方案存在的问题如下：

同步双写方案是只有在消息在主节点和从节点上都写成功后才会返回确认成功状态，服务可用性和数据可用性都非常高。但同步双写是一种阻塞模式，主节点的消息处理线程需要等待消息被同步到从节点才能处理新的消息请求，性能方面比异步复制模式低，发送单个消息的RT时间也会增高。

在同一个RocketMQ集群中，Broker之间的主节点和从节点只能配置一种同步模式，需要根据具体的业务场景在性能和消息零丢失上做平衡。如果特定的业务场景需要在消息零丢失同时还需要对消息收发性能具有很高要求，以上两种同步方式显然都无法满足。

针对现有技术存在的使用异步复制时信息丢失以及同步双写处理速度慢的问题，本申请实施例利用异步任务(CompletableFuture)对线程处理消息的过程进行异步化改造，主节点不需要等待从节点的消息同步成功确认即可对下一个消息请求进行处理，实现了一种流水线的形式来处理主节点和从节点之间的消息复制。

CompletableFuture是JDK1.8内置的一个用于异步编程的类，实现了Future接口，异步任务是对Future接口的一个扩展，增加了异步回调、流式处理、多个Future组合处理的能力，使Java在处理多任务的协同工作时更加顺畅便利。其中，Future接口是Java标准应用程序接口(Application Programming Interface，API)的一部分。Future接口是Java线程Future模式的实现，可以来进行异步计算。

本申请实施例的方案虽然是使用了常见的异步线程实现并行化，提升效率，但和异步复制较大的区别是本提案采用了一种任务划分的机制，将每个消息处理的过程分为多个异步任务，任务1(消息同步任务)负责消息同步，任务2(消息落盘任务)负责消息落盘、任务3(消息处理任务)负责将消息存入缓存和返回确认，其中，任务3等待获取任务1和任务2的执行结果后开始执行返回确认。

图3B为本申请实施例提供的一种消息同步方法的流程示意图，如图3B所示，包括以下步骤：

步骤S311、主节点接收客户端发送的消息，并交给业务处理线程；

在实施过程中，可以通过远程过程调用请求接收客户端发送的消息。

在一些实施例中，生产者客户端发送消息请求后，可以由默认的通信框架Netty处理，其中，Netty是一个异步通信框架，架构特点是：异步非阻塞、基于事件驱动、高性能、高可靠性和高可定制性。Netty框架的主要线程是输入输出(Input Output，IO)线程。NettyIO线程把请求交给Broker中的业务处理线程(SendMessageProcessor)进行处理。

步骤S312、业务处理线程处理接收到的消息；

在实施过程中，业务处理线程生成一个任务3(消息处理任务)并立即返回，业务处理线程马上处理新的消息发送请求。

步骤S313、业务处理线程创建任务3，任务3将消息写入主节点的缓存；

步骤S314、业务处理线程创建任务1(消息同步任务)，任务1向从节点复制消息；

在一些实施例中，任务1提交请求(GroupCommitRequest)到同步复制服务(HAService)，等待返回服务(GroupTransferService)通知消息，以表征同步被完成，即，复制位点大于等于该消息的写入位点。

图3B中所示的控制流32用于控制从节点返回消息，该返回消息即返回GroupTransferService通知消息，以表征同步被完成。

步骤S315、业务处理线程创建任务2(消息落盘任务)，任务2将消息刷盘到磁盘，以实现消息落盘；

这里，落盘就是将数据写入到磁盘(存储介质)；刷盘并不是每次接收到数据后就将数据写入到磁盘，而是会先写入缓冲区，将缓冲区的数据写入到磁盘的过程，称为刷盘。

在一些实施例中，消息落盘即任务2将缓存中的消息数据写入到本地的消息存储文件(commitlog)中。

图3B中所示的控制流33，用于通过刷盘将缓存中的消息数据写入到本地磁盘中。

步骤S316、任务3整合任务1和任务2的执行结果；

待上述两个异步处理任务(任务1和任务2)都执行完成后，消息处理线程整合这两个异步任务执行结果。

步骤S317、任务3在确定任务1和任务2执行成功的情况下，向客户端返回确认响应。

本申请实施例中，生产者发送的消息到达主节点后，业务处理线程不再等待消息复制至从节点后再处理新请求，而是提前生成异步任务去执行复制任务后返回，并马上处理新的消息请求。确认操作由其他线程确认之后再进行结果处理并返回给客户端。通过对复制过程进行切分并将其流水线化，减少线程的长时间等待，充分利用CPU，从而大幅提高吞吐量。

图4A为本申请实施例提供的异步复制、同步双写和优化后的异步任务三种方式每秒处理的消息数量的示意图，如图4A所示，该示意图中异步复制每秒处理108400个消息，同步双写每秒处理10300个消息，优化后的异步任务每秒处理108300个消息，其中，优化后的异步任务为本申请实施例提供的消息同步方法。

通过异步复制、同步双写和使用本申请提供的异步任务三种方式对消息队列RocketMQ集群吞吐量和延迟的测试比较，使用异步任务优化后，消息队列每秒处理的消息数量(吞吐量)提升非常明显，相比优化前提升十倍，基本与异步复制吞吐量持平。

图4B为本申请实施例提供的异步复制、同步双写和优化后的异步任务三种方式延时指标的比对示意图，如图4B所示，横轴为时延，单位为毫秒(ms)，纵轴为不同的百分率(percentage，PCT)，其中，在百分率为99.9的情况下，异步复制的时延为8.4毫秒，同步双写的时延为28毫秒，优化后的异步任务时延为8.7毫秒；在百分率为99的情况下，异步复制的时延为2.8毫秒，同步双写的时延为26毫秒，优化后的异步任务时延为3毫秒；在百分率为50的情况下，异步复制的时延为2毫秒，同步双写的时延为18毫秒，优化后的异步任务时延为2毫秒；在平均(avg)的情况下，异步复制的时延为1.7毫秒，同步双写的时延为18.7毫秒，优化后的异步任务时延为1.8毫秒。

基于以上图4B中的数据，可以看出在延迟方面，优化后的异步任务相比之前同步双写方式有明显的降低。

基于前述的实施例，本申请实施例提供一种消息同步装置，该装置包括所包括的各模块，各模块包括各子模块，各子模块包括单元，可以通过电子设备中的处理器来实现；当然也可通过具体的逻辑电路实现；在实施的过程中，处理器可以为中央处理器(CPU)、微处理器(MPU)、数字信号处理器(DSP)或现场可编程门阵列(FPGA)等。

图5为本申请实施例提供的消息同步装置的组成结构示意图，如图5所示，所述装置500包括：

接收模块501，用于接收客户端发送的待处理消息；

处理模块502，用于在同步所述待处理消息的同时，接收所述客户端发送的新的待处理消息，其中，所述同步包括将所述待处理消息复制至从节点；

第一返回模块503，用于在预设时间段内，确定所述待处理消息成功复制至所述从节点的情况下，返回同步成功消息至所述客户端，其中，所述同步成功消息用于表征所述待处理消息同步成功。

在一些实施例中，所述同步还包括将所述待处理消息保存至所述主节点的磁盘，所述处理模块包括保存子模块和复制子模块，其中，所述保存子模块，用于将所述待处理消息保存至所述主节点的磁盘；所述复制子模块，用于将所述待处理消息复制至从节点。

在一些实施例中，所述保存子模块包括第一写入单元和第二写入单元，其中，所述第一写入单元，用于将所述待处理消息写入所述主节点的缓存；所述第二写入单元，用于将所述缓存中的待处理消息写入所述主节点的消息存储文件。

在一些实施例中，所述复制子模块包括提交单元和确定单元，其中，所述提交单元，用于提交同步请求到同步复制服务，其中，所述同步请求包括所述待处理消息；所述确定单元，用于在所述同步复制服务确定所述从节点完成复制所述待处理消息的情况下，确定将所述待处理消息复制至从节点。

在一些实施例中，所述第一返回模块，还用于在预设时间段内，确定所述待处理消息成功保存至所述主节点的磁盘和所述待处理消息成功复制至从节点的情况下，返回同步成功消息至所述客户端。

在一些实施例中，所述装置还包括第二返回模块和获取模块，其中，所述第二返回模块，用于在所述预设时间段内，确定所述待处理消息未成功保存至所述主节点的磁盘，和/或所述待处理消息未成功复制至所述从节点的情况下，向所述客户端返回同步失败消息，其中，所述同步失败消息用于表征所述待处理消息同步失败；所述获取模块，用于在所述待处理消息同步失败的情况下，重新获取所述待处理消息。

以上装置实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请装置实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

需要说明的是，本申请实施例中，如果以软件功能模块的形式实现上述方法，并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得电子设备(可以是手机、平板电脑、笔记本电脑、台式计算机等)执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read Only Memory，ROM)、磁碟或者光盘等各种可以存储程序代码的介质。这样，本申请实施例不限制于任何特定的硬件和软件结合。

对应地，本申请实施例提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述实施例中提供的消息同步方法中的步骤。

对应地，本申请实施例提供一种电子设备，图6为本申请实施例提供的电子设备的一种硬件实体示意图，如图6所示，该设备600的硬件实体包括：包括存储器601和处理器602，所述存储器601存储有可在处理器602上运行的计算机程序，所述处理器602执行所述程序时实现上述实施例中提供的消息同步方法中的步骤。

存储器601配置为存储由处理器602可执行的指令和应用，还可以缓存待处理器602以及电子设备600中各模块待处理或已经处理的数据(例如，图像数据、音频数据、语音通信数据和视频通信数据)，可以通过闪存(FLASH)或随机访问存储器(Random AccessMemory，RAM)实现。

这里需要指出的是：以上存储介质和设备实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请存储介质和设备实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

应理解，说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本申请的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在一实施例中”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。

上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元；既可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。

另外，在本申请各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(Read Only Memory，ROM)、磁碟或者光盘等各种可以存储程序代码的介质。

或者，本申请上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得电子设备(可以是手机、平板电脑、笔记本电脑、台式计算机等)执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、ROM、磁碟或者光盘等各种可以存储程序代码的介质。

本申请所提供的几个方法实施例中所揭露的方法，在不冲突的情况下可以任意组合，得到新的方法实施例。

本申请所提供的几个产品实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的产品实施例。

本申请所提供的几个方法或设备实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的方法实施例或设备实施例。

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

Claims (10)

1.一种消息同步方法，应用于主节点，其特征在于，所述方法包括：

接收客户端发送的待处理消息；

在同步所述待处理消息的同时，接收所述客户端发送的新的待处理消息，其中，所述同步包括将所述待处理消息复制至从节点；

在预设时间段内，确定所述待处理消息成功复制至所述从节点的情况下，返回同步成功消息至所述客户端，其中，所述同步成功消息用于表征所述待处理消息同步成功。

2.如权利要求1所述的方法，其特征在于，所述同步还包括将所述待处理消息保存至所述主节点的磁盘，

所述同步所述待处理消息，包括：

将所述待处理消息保存至所述主节点的磁盘；

将所述待处理消息复制至所述从节点。

3.如权利要求2所述的方法，其特征在于，所述将所述待处理消息保存至所述主节点的磁盘，包括：

将所述待处理消息写入所述主节点的缓存；

将所述缓存中的待处理消息写入所述主节点的消息存储文件。

4.如权利要求2所述的方法，其特征在于，所述将所述待处理消息复制至所述从节点，包括：

提交同步请求到同步复制服务，其中，所述同步请求包括所述待处理消息；

在所述同步复制服务确定所述从节点完成复制所述待处理消息的情况下，确定将所述待处理消息复制至从节点。

5.如权利要求2所述的方法，其特征在于，所述在预设时间段内，确定所述待处理消息成功复制至所述从节点的情况下，返回同步成功消息至所述客户端，包括：

在预设时间段内，确定所述待处理消息成功保存至所述主节点的磁盘和所述待处理消息成功复制至从节点的情况下，返回同步成功消息至所述客户端。

6.如权利要求2至5任一项所述的方法，其特征在于，所述方法还包括：

在所述预设时间段内，确定所述待处理消息未成功保存至所述主节点的磁盘，和/或所述待处理消息未成功复制至所述从节点的情况下，向所述客户端返回同步失败消息，其中，所述同步失败消息用于表征所述待处理消息同步失败；

在所述待处理消息同步失败的情况下，重新获取所述待处理消息。

7.如权利要求5所述的方法，其特征在于，所述主节点包括业务处理线程，

所述接收客户端发送的待处理消息，包括：

所述业务处理线程利用通信模块接收所述客户端发送的待处理消息；

对应地，所述在同步所述待处理消息的同时，接收所述客户端发送的新的待处理消息，包括：

所述业务处理线程创建消息处理任务，同时接收所述客户端发送的新的待处理消息；

所述消息处理任务将所述待处理消息写入缓存；

所述业务处理线程创建消息同步任务和消息落盘任务；

所述消息落盘任务将所述缓存中的所述待处理消息保存至所述主节点的磁盘；

所述消息同步任务将所述待处理消息复制至所述从节点；

对应地，所述预设时间段内，在确定所述待处理消息成功保存至所述主节点的磁盘和所述待处理消息成功复制至从节点的情况下，返回同步成功消息至所述客户端，包括：

预设时间段内，在所述消息处理任务确定所述消息同步任务将所述待处理消息成功保存至所述主节点的磁盘，和所述消息落盘任务将所述待处理消息成功复制至从节点的情况下，所述消息处理任务返回同步成功消息至所述客户端。

8.一种消息同步装置，其特征在于，所述装置包括：

接收模块，用于接收客户端发送的待处理消息；

处理模块，用于在同步所述待处理消息的同时，接收所述客户端发送的新的待处理消息，其中，所述同步包括将所述待处理消息复制至从节点；

第一返回模块，用于预设时间段内，在确定所述待处理消息成功复制至所述从节点的情况下，返回同步成功消息至所述客户端，其中，所述同步成功消息用于表征所述待处理消息同步成功。

9.一种电子设备，包括存储器和处理器，所述存储器存储有可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现权利要求1至7任一项所述方法中的步骤。

10.一种计算机存储介质，其特征在于，存储有可执行指令，用于引起处理器执行时，实现权利要求1至7任一项所述的方法中的步骤。

Images