CN106878473A - 一种消息处理方法、服务器集群及*** - Google Patents

Abstract

本申请提供了一种消息处理方法、服务器集群及***，该服务器集群包括多个队列服务器，目标队列服务器将第一客户端发送的请求消息写入目标日志文件时，触发服务器集群中的备份队列服务器同步该目标日志文件，在备份队列服务器将同步的请求消息推送至对应的备份消息队列，向目标队列服务器反馈备份完成信息，当目标队列服务器接收到第一预设数量的备份完成信息后，再将该请求消息推送至目标消息队列存储，并向第一客户端反馈针对该请求消息的成功响应信息，从而保证请求消息的生产可靠性以及存储可靠性；而且，由于本申请采用多副本机制，从而保证了目标队列服务器工作异常的情况下，***的可靠性以及可用性。

Description

一种消息处理方法、服务器集群及***

技术领域

本申请主要涉及消息处理应用领域，更具体地说是涉及一种消息处理方法、服务器集群及***。

背景技术

在各领域应用中，客户端之间的消息传输已成为实现应用业务的基本过程，参照图1(a)所示，传统的消息传输通常是消息生产者与消息消费者进行一对一传输，很容易导致消息丢失，且往往无法实现消息复用，影响工作效率。

为了解决上述问题，如图1(b)所示，目前通常会在消息生产者与消息消费者之间设置开源消息队列中间件，用来存储消息生产者生成的消息，并根据需要转发至消息消费者，实现了消息复用，且避免了因突然产生大量消息而导致消息的丢失等问题。

然而，现有的开源消息队列中间件主要采用单击或主从结构，一旦其中的某一个节点发生故障，将会导致整个***不可用，在此期间若有丢失的消息，将导致消息不可回溯，从而影响***的可靠且稳定运行；而且，当调整开源消息队列中间件中节点数量时，将会引发全局的数据重新均衡，影响***可用性。

发明内容

有鉴于此，本申请提供了一种消息处理方法、服务器集群及***，采用多副本的备份机制，在目标队列服务器工作异常情况下，保证了***的可靠性以及稳定性。

为了实现上述目的，本申请提供了以下技术方案：

本申请实施例提供了一种消息处理方法，应用于服务器集群，所述服务器集群包括多个队列服务器，所述方法包括：

目标队列服务器获得第一客户端发送的请求消息，所述目标队列服务器是所述多个队列服务器中的任意一个队列服务器，将所述多个队列服务器中的其他队列服务器作为备份队列服务器；

所述目标队列服务器将所述请求消息写入目标日志文件，并触发所述备份队列服务器同步所述目标日志文件；

所述备份队列服务器将同步的所述请求消息推送至对应的备份消息队列存储，并向所述目标队列服务器反馈备份完成信息；

所述目标队列服务器接收到第一预设数量的所述备份队列服务器反馈的所述备份完成信息，将所述请求消息推送至目标消息队列存储，并向所述第一客户端反馈针对所述请求消息的成功响应信息。

本申请实施例还提供了一种服务器集群，包括：一个目标队列服务器以及多个备份队列服务器，其中：

所述目标队列服务器，用于获得第一客户端发送的请求消息，并将所述请求消息写入目标日志文件，触发所述备份队列服务器同步所述目标日志文件；

所述备份队列服务器，用于将同步的所述请求消息推送至对应的备份消息队列存储，并向所述目标队列服务器反馈备份完成信息，以使所述目标队列服务器接收到第一预设数量的所述备份队列服务器反馈的所述备份完成信息，将所述请求消息推送至目标消息队列存储，并向所述第一客户端反馈针对所述请求消息的成功响应信息。

本申请实施例还提供了一种消息处理***，其特征在于，所述***包括：多个客户端以及至少一个如上所述的服务器集群。

由此可见，与现有技术相比，本申请提供了一种消息处理方法、服务器集群及***，该服务器集群包括多个队列服务器，将其中任意一个队列服务器作为目标队列服务器，其他队列服务器作为备份队列服务器，目标队列服务器获得第一客户端发送的请求消息，并将其写入目标日志文件时，将触发该服务器集群中的备份队列服务器同步该目标日志文件，之后，备份队列服务器将同步的请求消息推送至对应的备份消息队列，并向目标队列服务器反馈备份完成信息，当目标队列服务器接收到第一预设数量的备份完成信息后，再将该请求消息推送至目标消息队列存储，并向第一客户端反馈针对该请求消息的成功响应信息，从而保证请求消息的生产可靠性以及存储可靠性；而且，由于本申请采用多副本机制，从而保证了目标队列服务器工作异常的情况下，***的可靠性以及可用性。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1(a)和图1(b)为本申请提供的两种现有的消息处理方法的示意图；

图2为本申请实施例提供的一种消息处理方法的实现***结构图；

图3为本申请实施例提供的一种消息处理方法的信令流程图；

图4为本申请实施例提供的一种消息处理方法的部分流程图；

图5为本申请实施例提供的一种消息复用应用示意图；

图6为本申请实施例提供的一种服务器集群的结构示意图；

图7为本申请实施例提供的一种服务器集群中的队列服务器的结构框图；

图8为本申请实施例提供的另一种服务器集群中的队列服务器的结构框图；

图9为本申请实施例提供的又一种服务器集群中的队列服务器的结构框图；

图10为本申请实施例提供的一种消息队列的***应用示意图；

图11为本申请实施例提供的一种服务器集群中的队列服务器的硬件结构图。

具体实施方式

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

为了使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。其中，为了方便理解本申请技术方案，将对下文实施例可能涉及到的技术术语进行解释说明，具体如下：

producer：消息生产者，负责生产消息；

consumer：消息消费者，负责消费消息，在本申请中，消息消费者和消息生产者可以是不同的客户端；

broker：消息中间件，负责消息的存储，转发，一般也称作队列服务器，即MQ(MessageQueue，消息队列)server；

queue:队列模型，生产者发送消息到broker的队列，消费者从broker队列消费消息。

leader:领导者，即下文描述的目标队列服务器，broker中引入replication(复制)机制，每个partition(分区)可能会有多个备份，因此需要在多个MQ server中选出一个leader，producer和consumer只与这个leader交互，其他的MQ server作为follower从leader中复制数据；

follower：跟随者，即下文描述的备份队列服务器，在本申请中，可以从leader中复制数据，保证***可靠运行。

如图2所示，为本申请实施例提供的消息处理方法的实现***架构图，该***可以包括：多个客户端21以及至少一个服务器集群22，每个服务器集群可以包括多个队列服务器23。

其中，客户端21可以是装载在手机、平板电脑、笔记本电脑等用户设备上，在实际应用中，通过与队列服务器13建立通信连接，实现信息交互。

可选的，客户端21可以是从官方网站或应用中心等下载并安装到用户设备上的应用程序，也可以是以浏览器的形式存在，本申请对客户端21的存在形式不作限定。

在本申请实际应用中，客户端可以包括支付客户端、充值客户端以及实现订单查询等功能的业务客户端，具体可以根据实际业务需要确定，本申请对此不作限定。

队列服务器23可以作为消息队列中间件，在实际应用中，可以将多个队列服务器23组成的服务器集群作为一个Broker set，从而保证消息的可靠性和可用性。其中，在本申请提供的***可以包括多个Broker set，具体可以根据实际需要确定。

在本申请中，队列服务器可以作为两个客户端之间进行消息交互的中间件，如客户端A将消息发送至队列服务器进行存储，以使客户端B根据需要从该队列服务器读取相应消息，从而避免客户端A发送大量消息至客户端B，客户端B无法及时读取所有消息，导致消息丢失等问题。

可选的，每个队列服务器可以包括存储请求消息、操作数据等日志文件内容的存储器、存储消息队列的状态机等，本申请对该队列服务器的具体结果不作限定，而且，本申请中各队列服务器的组合结构可以相同，从而保证各备份队列服务器能够同步目标队列服务器的操作。

其中，状态机由状态寄存器和组合逻辑电路构成，能够根据控制信号按照预先设定的状态进行状态转移，是协调相关信号动作、完成特定操作的控制中心。在本申请中，上述状态机可以称为MQ状态机，将接收到的消息写入相应的消息队列，以便其他客户端从该消息队列读取所需消息。

基于图2示出的***架构，图3示出了本申请实施例提供的一种消息处理方法的信令流程图，该方法可以包括以下步骤：

步骤S31，第一客户端向目标队列服务器发送请求消息；

在本实施例中，第一客户端可以是消息队列的消息生产者，在工作过程中产生请求消息，可以主动发送至队列服务器，也可以是在接收到队列服务器周期发送的查询请求后，响应该查询请求，从而将产生的请求消息发送至队列服务器等。由此可见，目标队列服务器获得第一客户端生成的请求消息的方式并不局限于步骤S31所述的方式，可以根据实际需要确定。

步骤S32，目标队列服务器将该请求消息写入目标日志文件，并触发备份队列服务器同步该目标日志文件；

在本实施例中，***中的每一个服务器集群可以包括多个队列服务器，在实际应用中，为了保证消息队列的一致性和唯一性，可以从多个队列服务器中选择一个队列服务器作为目标队列服务器，实现对第一客户端发送的请求消息的处理，同时将该服务器集群中的其他队列服务器作为备份队列服务器，实现对目标队列服务器操作的同步。

其中，关于从多个队列服务器中确定目标队列服务器的过程可以参照下文对应实施例的描述，本实施例在此不再详述。需要说明的是，同一时间内***只有一个目标队列服务器。

如上所述，本申请可以采用多副本机制实现对第一客户端生成的请求消息的处理，也就是说，对于目标队列服务器对第一客户端生成的请求消息的操作，将会由多个备份队列服务器进行同步，具体可以包括复制目标队列服务器的目标日志文件等同步操作，以便备份队列服务器能够根据该目标日志文件替代目标服务器继续工作，从而保证***工作稳定性。

可选的，在实际应用中，目标队列服务器接收到第一客户端发送的请求消息后，可以通过raft一致性模块按照请求顺序，将该请求消息写入目标日志文件，并将所得的最新日志文件按照预设顺序，通过网络依次发送至各备份队列服务器进行同步处理，从而保证服务器集群中各队列服务器中日志文件包含的请求消息与第一客户端发送的请求消息的顺序和内容一致。

其中，在备份队列服务器同步目标队列服务器的操作过程中，可以利用一致性算法保证所同步请求消息的严格一致，本申请对该一致性算法的具体内容不作限定。

步骤S33，备份队列服务器将同步的请求消息推送至对应的备份消息队列存储，向目标队列服务器反馈备份完成信息；

在本申请中，各队列服务器的结构相同，备份队列服务器完成请求消息的备份后，即实现对目标队列服务器的日志文件的复制等同步操作后，可以将所要备份的请求消息写入消息队列存储，之后，可以向目标队列服务器返备份完成信息，以使目标队列服务器得知当前有多少个备份队列服务器完成同步操作。

步骤S34，目标队列服务器判断接收到的备份完成信息的数量是否达到第一预设数量，如果是，进入步骤S35；如果否，返回步骤S32触发备份服务器继续同步目标日志文件；

其中，第一预设数量可以根据服务器集群包含的队列服务器的数量确定，本申请并不限定其具体数量，通常不小于该服务器集群包含的备份队列服务器的一半。

步骤S35，目标队列服务器将请求消息推送至目标消息队列存储；

在本实施例中，当目标队列服务器确定大部分备份队列服务器备份成功后，才会将所得到的请求消息写入消息队列，具体可以是先将请求消息提交至该目标队列服务器的MQ状态机，再由该MQ状态机将请求消息写入相应的消息队列中，从而保证消息队列对请求消息存储的可靠性。

需要说明的是，本申请对目标队列服务器将接收到的请求消息写入消息队列的具体实现过程不作限定。

步骤S36，目标队列服务器向第一客户端反馈针对请求消息的成功响应信息。

结合上述分析，为了保证第一客户端传输请求消息的可靠性，本申请目标队列服务器确定大多数备份队列服务器完成备份操作后，可以告知第一客户端即消息生产者这一处理结果。

可选的，若第一客户端在一定时间内没有接收到目标队列服务器反馈的针对请求消息的成功响应信息，可以重新向该目标队列服务器发送请求消息，从而确保该请求消息成功发送至目标队列服务器。

步骤S37，目标队列服务器接收第二客户端发送的消息读取请求；

在本申请中，该第二客户端可以作为消息队列中的消息消费者，其与产生请求消息的第一客户端不同。

步骤S38，目标队列服务器响应该消息读取请求，确定目标请求消息；

在实际应用中，第二客户端发送的消息读取请求中可以包括指示需要读取的目标请求消息的标识信息，如该目标请求消息的名称、代码、生产顺序等，以便目标队列服务器能够基于该消息读取请求，准确得知第二客户端需要读取的目标请求消息。

步骤S39，目标队列服务器将该目标请求消息发送至第二客户端；

在本申请中，消息生产者产生的一条请求消息可以被多种类型消息消费者订阅，如订单数据生产一次，对账、监控、统计模块都可以消费，且在请求消息有效期内，确保请求消息至少被成功消费或读取一次。可见，本申请达到了一次生产多次消费的技术效果。

而且，由于本申请采用消息队列的方式实现请求消息的存储，保证了请求消息的顺序性，且消费端能够根据实际需要从消息队列读取请求消息，不会造成请求消息的丢失。

步骤S310，目标队列服务器检测该请求消息的存储时间是否达到预设阈值，如果是，进入步骤S311；如果否，继续检测。

步骤S311，目标队列服务器删除消息队列存储的该请求消息。

在本申请中，消息队列可以应用发布/订阅模型，从而使该消息队列存储的请求消息能够被多次复用。而且，本申请针对存储的请求消息设置了最长存储时间即上述预设阈值，从请求消息进入消息队列开始计时，在其存储时间达到该预设阈值时，该消息队列将会自动删除该请求消息，从而下一个请求消息留出存储空间。

需要说明的是，关于删除消息队列中的请求消息的方式并不局限于上文列举的方式，还可以是在其他客户端从该消息队列读取所需请求消息后，触发目标队列服务器删除该消息队列中的请求消息，以保证该消息队列能够容纳后续接收到的请求消息。

下面将对从服务器集群中的多个队列服务器中重新选择目标队列服务器的实现过程进行说明。

如图4所示，为本申请实施例提供的另一种消息处理方法的部分流程图，该方法主要从服务器集群的角度进行描述，如上所述，该服务器集群可以包括多个队列服务器，则本实施例提供的该方法可以包括：

步骤S41，备份队列服务器判断第一预设时间内是否接收到目标队列服务器发送的续期信息；如果否，进入步骤S42；如果是，继续判断。

在本申请实际应用中，服务器集群中的目标队列服务器可以按照预设周期向该服务器集群中的其他队列服务器发送续期信息，以使其他队列服务器得知当前该服务器集群中有目标队列服务器，避免在该服务器集群中选定重复的目标队列服务器，即保证服务器集群中同一时间只有一个目标队列服务器。

基于此，由于对服务器集群初始化后，其包含的队列服务器可以作为备份队列服务器，而对于这些备份队列服务器来说，可以通过判断其在第一预设时间内是否接收到目标队列服务器发送的续期信息的方式，来获知该目标队列服务器是否故障，该服务器集群是否需要重选目标队列服务器。

需要说明的是，本申请的目标队列服务器和备份队列服务器之间是并列关系，而非主从关系，从而使本申请能够利用备份队列服务器实现对目标队列服务器的扩展，解决了现有的开源中间件因单机或主从结构，存在的单点问题以及请求消息的不可回溯等技术问题。

步骤S42，将该备份队列服务器确定为候选队列服务器，并向服务器集群中的其他队列服务器发送选举请求；

由于目标队列服务器出现宕机或者不可用等故障时，将会导致***不可用，为了保证***运行可靠性，本申请需要及时检测这一情况，并重新选择目标队列服务器，如上述分析，本实施例将通过备份队列服务器在第一预设时间内是否接收到目标队列服务器的续期信息的方式，判断该目标队列服务器是否正常工作，一旦备份队列服务器在第一预设时间内没有接收到目标队列服务器的续期信息，可以触发***重新选择目标队列服务器。

在本申请中，可以将满足上述条件的备份队列服务器作为候选队列服务器，向所在服务器集群中的其他队列服务器发送选举请求，等待其他队列服务器的回复，以得知自己能否成为目标队列服务器。

步骤S43，候选队列服务器判断接收到的针对该选举请求的响应信息数量是否达到第二预设数量；如果是，执行步骤S45；如果否，进入步骤S44；

在本申请中，当候选队列服务器得到大部分队列服务器的选举，即接收到的大部分队列服务器反馈的响应信息后，才能成为目标队列服务器。由于服务器集群中的各队列服务器已知该服务器集群包含的队列服务器的总数量，所以，候选队列服务器能够根据接收到的响应信息数量以及该总数量，判断其能够成为目标队列服务器。

其中，需要说明的是，每一个队列服务器只能响应一个队列服务器发送的选举请求，从而保证在实际应用，当多个候选队列服务器发起选举请求的情况下，同一时间只有一个候选队列服务器得到大部分的投票，即大部分响应信息，此时，其他候选队列服务器将接收到新的目标队列服务器发送的续期信息后，重新转换为备份队列服务器。

基于此，第二预设数量可以大于服务器集群包含的队列服务器的总数量的一半数量，具体可以与上述第一预设数量相同，但并不局限于此。

步骤S44，候选队列服务器经第二预设时间向服务器集群中的其他队列服务器再次发送选举请求，并返回步骤S43；

其中，第二预设时间与第一预设时间可以相同，也可以不同，本申请对此不作限定。

步骤S45，候选队列服务器作为目标队列服务器向服务器集群中的其他队列服务器发送续期信息。

在本申请中，重新选定目标队列服务器后，将会及时告知所在服务器集群中的其他队列服务器，从而使当前的候选队列服务器转变为备份队列服务器，对新的目标队列服务器的操作进行同步。

综上所述，本申请采用备份机制，通过备份队列服务器对目标队列服务器接收到的请求消息以及操作进行同步复制，保证请求消息具有多个副本，且通过一致性算法保证了复制的日志文件的严格一致性，从而提高了***的可靠性。而且，在目标队列服务器工作异常时，本申请能够及时选择一个新的目标队列服务器对客户端发送的请求消息进行处理，保证了***的稳定性以及可用性。

基于上述实施例描述的消息处理方案，由于本申请仍采用队列服务器存储消息，从而使消息消费者能够根据实际情况选择所需消息，避免了在一段时间内接收到大量消息，如春节发红包场景中，因红包流量非常大，而服务器***处理能力有限，很容易出现雪崩效应，导致服务器***崩溃，本申请采用将各红包消息存储到队列服务器，达到缓解大流量带来的冲击，避免了消息的丢失。

另外，如上述分析，消息队列中的请求消息被读取后并不会直接消失，因此，终端其他应用仍可以继续读取，如图5所示，用户通过终端生成的交易或下单消息，写入队列服务器后，库存管理、物流管理、积分管理以及CRM(Customer Relationship Management，客户关系管理)等应用模块均可以作为消息消费者，读取消息队列中的交易或下单消息。也就是说，队列服务器中的请求消息是可以多次复用的。

当然，本申请也可以针对消息队列中的请求消息设置一个最长存储时间即预设阈值，若请求消息的存储时间超过该运输阈值，消息队列可以自动删除该请求消息；或者，消息消费者不再需要读取该请求消息后，可以主动向该消息队列发送相应的删除指令，来删除该请求消息，保证该消息队列能够容纳后续产生的数据，本申请对消息队列中请求消息的具体管理方式不作限定。

基于图2所示的***架构，图6示出了本申请实施例提供的一种服务器集群的结构示意图，该服务器集群可以包括多个队列服务器，在本申请中可以将其中的一个队列服务器作为目标队列服务器61，并将其他队列服务器作为备份队列服务器62，其中：

目标队列服务器61，用于获得第一客户端发送的请求消息，并将所述请求消息写入目标日志文件，触发所述备份队列服务器同步所述目标日志文件；

在本实施例中，为了保证数据的严格一致性，目标队列服务器可以采用一致性算法将接收到的请求消息写入目标日志文件。其中，该一致性算法可以存在目标队列服务器的一致性模块中，基于上述分析可知，服务器集群中的每一个队列服务器都具有该一致性模块，从而保证任意一个队列服务器作为目标队列服务器进行消息处理过程中，数据的严格一致性。

备份队列服务器62，用于将同步的所述请求消息推送至对应的备份消息队列存储，并向所述目标队列服务器反馈备份完成信息，以使所述目标队列服务器41接收到第一预设数量的所述备份队列服务器反馈的所述备份完成信息，将所述请求消息推送至目标消息队列存储，并向所述第一客户端反馈针对所述请求消息的成功响应信息。

可选的，在实际应用中，备份队列服务器62还可以用于：检测到所述目标队列服务器工作异常，按照预设算法，重新选择所述服务器集群的目标队列服务器。

为了实现从服务器集群中选择目标队列服务器，如图7所示，备份队列服务器62可以包括：

时间判断模块621，用于判断第一预设时间内是否接收到所述目标队列服务器发送的续期信息；

选举请求发送模块622，用于在时间判断模块的判断结果为否时，将所述备份队列服务器转变为候选队列服务器，并向服务器集群中的其他队列服务器发送选举请求；

数量判断模块623，用于判断接收到的针对选举请求的响应信息数量是否达到第二预设数量；

续期信息发送模块624，用于在数量判断模块的判断结果为是，将所述候选队列服务器转变为新的目标队列服务器，并向所述服务器集群中的其他队列服务器发送所述续期信息；

选举请求发送模块622还用于在数量判断模块的判断结果为否，经第二预设时间向所述服务器集群中的其他队列服务器再次发送所述选举请求，直至接收到的所述响应信息数量达到所述第二预设数量，或者接收到新的目标队列服务器发送的续期信息。

需要说明的是，由于服务器集群中的备份队列服务器、候选队列服务器以及目标队列服务器是可以相互转化的，也就是说，对于同一个队列服务器来说，其在满足不同条件的情况下，可以是备份队列服务器，或者是候选队列服务器，或者是目标队列服务器，所以说，上图6所示的结构实际上是每一个队列服务器都可以具有的结构，只是其是在处于备份队列服务器的状态下实现上述功能。

另外，关于上文描述的确定服务器集群中的目标队列服务器的方法，并不局限于应用在目标队列服务器故障的情况下，还可以在服务器集群初始化，包含的均为备份队列服务器的情况下，按照上述方式选定目标队列服务器。

作为本申请另一实施例，在上述实施例的基础上，目标队列服务器还用于：检测所述目标消息队列存储的请求消息的存储时间是否达到预设阈值，基于检测结果，删除达到所述预设阈值的存储时间对应的请求消息，并触发所述备份队列服务器同步所述目标队列服务器的删除操作。

可选的，目标队列服务器还可以用于：响应第二客户端发送的消息读取请求，确定目标请求消息，并将所述目标请求消息发送至所述第二客户端，接收到所述第二客户端发送的消息读取完成信息，删除目标消息队列存储的所述目标请求消息；或者，将目标消息队列存储的请求消息推送至相应的第二客户端

参照图8，是从功能模块组成结构上说明队列服务器的结构，因此，当队列服务器作为目标队列服务器时，可以包括：

请求消息获得模块611，用于获得第一客户端发送的请求消息；

请求消息存储模块612，用于将所述请求消息写入目标日志文件，并触发所述备份队列服务器同步所述目标日志文件；

消息队列模块613，用于接收到第一预设数量的所述备份队列服务器反馈的所述备份完成信息，将所述请求消息推送至目标消息队列存储；

请求消息反馈模块614，用于向所述第一客户端反馈针对所述请求消息的成功响应信息。

需要说明的是，关于上述各功能模块的具体实现过程可以参照上述方法实施例对应部分的描述，本实施例在此不再详述。

可选的，在上述功能模块的结构基础上，如图9所示，目标队列服务器还可以包括：

时间检测模块615，用于检测所述目标消息队列存储的请求消息的存储时间是否达到预设阈值；

请求消息删除模块616，用于基于检测结果，删除达到所述预设阈值的存储时间对应的请求消息，并触发所述备份队列服务器同步所述目标队列服务器的删除操作。

可选的，在上述各实施例的基础上，目标队列服务器还可以包括：

读取请求获得模块，用于接收第二客户端发送的消息读取请求；

请求响应模块，用于响应第二客户端发送的消息读取请求，确定目标请求消息；

消息发送模块，用于将所述目标请求消息发送至所述第二客户端；

请求消息删除模块还可以用于接收到所述第二客户端发送的消息读取完成信息，删除目标消息队列存储的所述目标请求消息。

作为本申请另一实施例，目标队列服务器也可以将其目标消息队列存储的请求消息推送至相应的第二客户端，并不局限于上述第二客户端拉取请求消息的消息获得方式。

综上，本申请提供的服务器集群采用备份机制，在确定多个队列服务器中的一个队列服务器为目标队列服务器，其他为备份队列服务器后，将通过备份队列服务器对目标队列服务器接收到的请求消息以及操作进行同步复制，保证请求消息具有多个副本，且通过一致性算法保证了复制的日志文件的严格一致性，从而提高了***的可靠性。而且，在目标队列服务器工作异常时，本申请能够及时选择一个新的目标队列服务器对客户端发送的请求消息进行处理，保证了***的稳定性以及可用性。

结合上述对本申请提供的消息处理方案的分析，以及图10所示的***结构图，但并不局限于图10所示的消息服务器集群所在***的组成结构。在实际应用中，消息生产和消费均可以由目标队列服务器负责。

如图10所示，消息生产者与消息消费者工作过程中，相应的队列数据采集器会将采集业务数据或消息，并通过***主节点发送至数据库存储，以便管理***从中调取所需数据或消息。在实际应用中，***监控器也可以通过对消息生产者和消息消费者的队列数据采集器进行监控，以获得队列数据采集器采集到的业务数据或消息等信息，并发送至数据库存储。并且，根据实际需要，管理***可以通过该监控器实现对各队列数据采集器的控制，来控制队列数据采集器对特定业务数据或消息进行采集等等。

另外，消息生产者与消息消费者还可以通过各自的队列数据采集器，向队列服务器发送或获取请求消息，关于该队列服务器对接收到的请求消息的处理过程可以参照上述方法实施例的描述，本实施例在此不再赘述。其中，图10所示的队列服务器可以包括上述实施例描述的目标队列服务器以及备份队列服务器，以保证了消息队列的多副本机制，在遇到突发情况时，可以通过备份队列服务器来恢复服务。

下面将从硬件结构来说明服务器集群中的每一个队列服务器的结构。

如图11所示，为本申请实施例提供的一种队列服务器的硬件结构示意图，该队列服务器可以包括处理器111、通信接口112、存储器113以及通信总线114；

其中，处理器111、通信接口112、存储器113可以通过通信总线114完成相互间的通信；

可选的，通信接口112可以为通信模块的接口，如GSM模块的接口；

处理器111可能是一个中央处理器CPU，或者是特定集成电路ASIC(ApplicationSpecific Integrated Circuit)，或者是被配置成实施本申请实施例的一个或多个集成电路。

存储器113可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。

其中，处理器111具体用于：

目标队列服务器获得第一客户端发送的请求消息，所述目标队列服务器是所述多个队列服务器中的任意一个队列服务器，将所述多个队列服务器中的其他队列服务器作为备份队列服务器；

所述目标队列服务器将所述请求消息写入目标日志文件，并触发所述备份队列服务器同步所述目标日志文件；

所述备份队列服务器将同步的所述请求消息推送至对应的备份消息队列存储，并向所述目标队列服务器反馈备份完成信息；

所述目标队列服务器接收到第一预设数量的所述备份队列服务器反馈的所述备份完成信息，将所述请求消息推送至目标消息队列存储，并向所述第一客户端反馈针对所述请求消息的成功响应信息。

参照上图2，本申请实施例还提供了一种消息处理***，该***可以包括多个客户端21以及至少一个服务器集群22，每个服务器集群可以包括多个队列服务器23。

在本申请中，作为消息生产者的第一客户端生成的请求消息可以发送至服务器集群中的目标队列服务器进行处理，并由该服务器集群中的其他队列服务器即备份队列服务器对目标队列服务器的操作进行同步，从而保证目标队列服务器故障后，能够从备份队列服务器中重新选择一个目标队列服务器，对第一客户端发送的请求消息进行处理，从而保证***的可靠性以及可用性。

需要说明的是，关于服务器集群实现上述功能的具体实现过程可以参照上述方法实施例对应部分的描述，本实施例在此不再详述。

最后，需要说明的是，关于上述各实施例中，诸如第一、第二等之类的关系术语仅仅用来将一个操作、单元或模块与另一个操作、单元或模块区分开来，而不一定要求或者暗示这些单元、操作或模块之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法或者***不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法或者***所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法或者***中还存在另外的相同要素。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的服务器集群以及***而言，由于其与实施例公开的方法对应，所以描述的比较简单，相关之处参见方法部分说明即可。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (12)

1.一种消息处理方法，其特征在于，应用于服务器集群，所述服务器集群包括多个队列服务器，所述方法包括：

目标队列服务器获得第一客户端发送的请求消息，所述目标队列服务器是所述多个队列服务器中的任意一个队列服务器，将所述多个队列服务器中的其他队列服务器作为备份队列服务器；

所述目标队列服务器将所述请求消息写入目标日志文件，并触发所述备份队列服务器同步所述目标日志文件；

所述备份队列服务器将同步的所述请求消息推送至对应的备份消息队列存储，并向所述目标队列服务器反馈备份完成信息；

所述目标队列服务器接收到第一预设数量的所述备份队列服务器反馈的所述备份完成信息，将所述请求消息推送至目标消息队列存储，并向所述第一客户端反馈针对所述请求消息的成功响应信息。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

检测到所述目标队列服务器工作异常，按照预设算法，重新选择所述服务器集群的目标队列服务器。

3.根据权利要求2所述的方法，其特征在于，所述检测到所述目标队列服务器工作异常，按照预设算法，重新选择所述服务器集群的目标队列服务器，包括：

所述备份队列服务器判断第一预设时间内是否接收到所述目标队列服务器发送的续期信息；

如果否，所述备份队列服务器转变为候选队列服务器，并向所述服务器集群中的其他队列服务器发送选举请求；

所述候选队列服务器判断接收到的针对所述选举请求的响应信息数量是否达到第二预设数量；

如果达到，所述候选队列服务器转变为新的目标队列服务器，并向所述服务器集群中的其他队列服务器发送所述续期信息；

如果未达到，所述候选队列服务器经第二预设时间向所述服务器集群中的其他队列服务器再次发送所述选举请求，直至接收到的所述响应信息数量达到所述第二预设数量，或者接收到新的目标队列服务器发送的续期信息。

4.根据权利要求1所述的方法，其特征在于，所述目标队列服务器将所述请求消息写入目标日志文件，包括：

所述目标队列服务器通过一致性算法将接收到的请求消息写入目标日志文件。

5.根据权利要求1所述的方法，其特征在于，所述方法还包括：

所述目标队列服务器检测所述目标消息队列存储的请求消息的存储时间是否达到预设阈值；

基于检测结果，删除达到所述预设阈值的存储时间对应的请求消息，并触发所述备份队列服务器同步所述目标队列服务器的删除操作。

6.根据权利要求1所述的方法，其特征在于，所述方法还包括：

所述目标队列服务器接收第二客户端发送的消息读取请求；

所述目标队列服务器响应所述消息读取请求，确定目标请求消息；

所述目标队列服务器将所述目标请求消息发送至所述第二客户端；

所述目标队列服务器接收到所述第二客户端发送的消息读取完成信息，删除目标消息队列存储的所述目标请求消息。

7.根据权利要求1所述的方法，其特征在于，所述方法还包括：

所述目标队列服务器将目标消息队列存储的请求消息推送至相应的第二客户端。

8.一种服务器集群，其特征在于，包括：一个目标队列服务器以及多个备份队列服务器，其中：

所述目标队列服务器，用于获得第一客户端发送的请求消息，并将所述请求消息写入目标日志文件，触发所述备份队列服务器同步所述目标日志文件；

所述备份队列服务器，用于将同步的所述请求消息推送至对应的备份消息队列存储，并向所述目标队列服务器反馈备份完成信息，以使所述目标队列服务器接收到第一预设数量的所述备份队列服务器反馈的所述备份完成信息，将所述请求消息推送至目标消息队列存储，并向所述第一客户端反馈针对所述请求消息的成功响应信息。

9.根据权利要求8所述的服务器集群，其特征在于，所述备份队列服务器还用于：

检测到所述目标队列服务器工作异常，按照预设算法，重新选择所述服务器集群的目标队列服务器。

10.根据权利要求8所述的服务器集群，其特征在于，所述目标队列服务器还用于：

检测所述目标消息队列存储的请求消息的存储时间是否达到预设阈值，基于检测结果，删除达到所述预设阈值的存储时间对应的请求消息，并触发所述备份队列服务器同步所述目标队列服务器的删除操作。

11.根据权利要求8所述的服务器集群，其特征在于，所述目标队列服务器还用于：

响应第二客户端发送的消息读取请求，确定目标请求消息，并将所述目标请求消息发送至所述第二客户端，接收到所述第二客户端发送的消息读取完成信息，删除目标消息队列存储的所述目标请求消息；

或者，将目标消息队列存储的请求消息推送至相应的第二客户端。

12.一种消息处理***，其特征在于，所述***包括：多个客户端以及至少一个如权利要求8-11任意一项所述的服务器集群。