CN115480929A - 一种同城多活数据中心下的消息处理方法及装置 - Google Patents

Abstract

本申请公开了一种同城多活数据中心下的消息处理方法及装置，该方法包括：确定待发送的业务消息；根据待发送的业务消息，通过自定义消息队列选择器获取消息队列的路由信息；根据消息队列的路由信息，将待发送的业务消息发送至与生产者端处于同一数据中心的第一服务端或者处于同城数据中心的第二服务端，以使第一服务端对应的消费者端对第一服务端的业务消息进行消费或者第二服务端对应的消费者端对第二服务端的业务消息进行消费。本申请通过自定义消息队列选择器能够将业务消息优先发送至本地数据中心的服务端，降低了消息发送的延迟性，当本地数据中心发生故障时，又能将业务消息直接发送至同城数据中心的服务端，避免了对实际业务造成影响。

Description

一种同城多活数据中心下的消息处理方法及装置

技术领域

本申请涉及计算机技术领域，尤其涉及一种同城多活数据中心下的消息处理方法及装置。

背景技术

消息队列可以看作是一个存放消息的容器，当用户需要使用消息的时候可以从消息队列中取出消息供自己使用。消息队列是分布式系统中重要的组件，使用消息队列主要是为了通过异步处理提高系统性能和削峰、降低系统耦合性。

在现有的基于消息队列搭建的分布式数据中心系统的架构下，每个数据中心的消息队列集群是相互独立的，本地数据中心的客户端的业务请求只会发送给本地数据中心的消息队列集群中的服务端。当本地数据中心的消息队列集群发生故障时，现有的方案通常是采用降级处理，并由事先搭建好的同城冷备集群接管本地数据中心的工作。

然而这种方案存在着资源利用不充分，且处理时效性不高等问题。

发明内容

本申请实施例提供一种同城多活数据中心下的消息处理方法及装置，以提高消息队列集群的资源利用率，提高业务处理效率。

本申请实施例采用下述技术方案：

第一方面，本申请实施例提供一种同城多活数据中心下的消息处理方法，由消息队列集群中的生产者端执行，其中，所述方法包括：

确定待发送的业务消息；

根据所述待发送的业务消息，通过自定义消息队列选择器获取消息队列的路由信息；

根据所述消息队列的路由信息，将所述待发送的业务消息发送至与所述生产者端处于同一数据中心的第一服务端，以使所述第一服务端对应的消费者端对所述第一服务端的业务消息进行消费；或者，根据所述消息队列的路由信息，将所述待发送的业务消息发送至与所述生产者端处于同城数据中心的第二服务端，以使所述第二服务端对应的消费者端对所述第二服务端的业务消息进行消费。

可选地，所述根据所述消息队列的路由信息，将所述待发送的业务消息发送至与所述生产者端处于同一数据中心的第一服务端，以使所述第一服务端对应的消费者端对所述第一服务端的业务消息进行消费；或者，根据所述消息队列的路由信息，将所述待发送的业务消息发送至与所述生产者端处于同城数据中心的第二服务端，以使所述第二服务端对应的消费者端对所述第二服务端的业务消息进行消费包括：

根据所述消息队列的路由信息，确定与所述生产者端处于同一数据中心的第一服务端是否存在Topic消息队列；

若存在，则将所述待发送的业务消息发送至与所述生产者端处于同一数据中心的第一服务端；

若不存在，则将所述待发送的业务消息发送至与所述生产者端处于同城数据中心的第二服务端。

可选地，所述自定义消息队列选择器中维护有多个生产者端所在的数据中心的数据中心标识，所述若不存在，则将所述待发送的业务消息发送至与所述生产者端处于同城数据中心的第二服务端包括：

通过所述自定义消息队列选择器查询与所述生产者端所在的数据中心的数据中心标识相对应的同城数据中心标识；

根据所述同城数据中心标识，将所述待发送的业务消息发送至所述同城数据中心标识对应的第二服务端。

可选地，所述将所述待发送的业务消息发送至所述同城数据中心标识对应的第二服务端包括：

根据所述消息队列的路由信息确定所述第二服务端是否存在Topic消息队列；

若存在，则将所述待发送的业务消息发送至所述第二服务端；

若不存在，则输出第一消息发送失败结果。

可选地，所述消息队列集群包括消息处理服务集群，所述消息处理服务集群中包括多个跨数据中心部署的消息处理服务节点，所述第一服务端和所述第二服务端均是指所述消息处理服务集群中的各消息处理服务节点，所述消息处理服务节点的名称中携带有数据中心标识，

所述根据所述消息队列的路由信息，将所述待发送的业务消息发送至与所述生产者端处于同一数据中心的第一服务端，以使所述第一服务端对应的消费者端对所述第一服务端的业务消息进行消费；或者，根据所述消息队列的路由信息，将所述待发送的业务消息发送至与所述生产者端处于同城数据中心的第二服务端，以使所述第二服务端对应的消费者端对所述第二服务端的业务消息进行消费包括：

根据所述消息处理服务节点的名称中携带的数据中心标识以及所述生产者端所在的数据中心的数据中心标识，确定与所述生产者端处于同一数据中心的第一服务端或者与所述生产者端处于同城数据中心的第二服务端。

可选地，在将所述待发送的业务消息发送至与所述生产者端处于同一数据中心的第一服务端或者与所述生产者端处于同城数据中心的第二服务端之后，所述方法还包括：

确定是否能够接收到所述第一服务端或者所述第二服务端返回的消息发送成功结果；

若不能，则输出第二消息发送失败结果。

可选地，在输出第二消息发送失败结果之后，所述方法还包括：

调用自定义消息重试接口；

通过所述自定义消息重试接口，对所述第二消息发送失败结果对应的业务信息重新发送。

可选地，所述自定义消息重试接口通过如下方式得到：

自定义生产者参数，并将用于发送业务消息的API接口进行包装；

将包装后的API接口与所述生产者端常用的API接口对齐，得到所述自定义消息重试接口。

可选地，所述消息队列集群包括配置信息服务集群，所述配置信息服务集群中包括多个跨数据中心部署的配置信息服务节点，所述通过自定义消息队列选择器获取消息队列的路由信息包括：

通过所述自定义消息队列选择器，从所述配置信息服务节点中获取所述消息队列的路由信息。

可选地，在确定待发送的业务消息之后，所述方法还包括：

在所述待发送的业务消息的Tag标签中设置数据中心标识，所述数据中心标识用于表征对业务消息进行消费的消费者端所在的数据中心的标识，以使所述消费者端根据所述Tag标签中设置数据中心标识对业务消息进行消费。

可选地，所述消息队列集群包括配置信息服务集群和消息处理服务集群，所述配置信息服务集群和消息处理服务集群通过如下方式得到：

搭建所述配置信息服务集群，所述配置信息服务集群中包括多个跨数据中心部署的配置信息服务节点；

搭建所述消息处理服务集群，所述消息处理服务集群中包括多个跨数据中心部署的消息处理服务节点；

将各消息处理服务节点的名称以及各消息处理服务节点上创建的Topic消息队列在所述配置信息服务集群中的各配置信息服务节点中均进行注册，以完成所述配置信息服务集群和所述消息处理服务集群的搭建。

第二方面，本申请实施例还提供一种同城多活数据中心下的消息处理装置，应用于消息队列集群中的生产者端，其中，所述装置用于实现前述之任一所述方法。

第三方面，本申请实施例还提供一种电子设备，包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行前述之任一所述方法。

第四方面，本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的电子设备执行时，使得所述电子设备执行前述之任一所述方法。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：本申请实施例的同城多活数据中心下的消息处理方法可以由消息队列集群中的生产者端来执行，在进行消息处理时，先确定待发送的业务消息，之后根据待发送的业务消息，通过自定义消息队列选择器获取消息队列的路由信息，最后根据消息队列的路由信息，将待发送的业务消息发送至与生产者端处于同一数据中心的第一服务端，以使第一服务端对应的消费者端对第一服务端的业务消息进行消费；或者，根据消息队列的路由信息，将待发送的业务消息发送至与生产者端处于同城数据中心的第二服务端，以使第二服务端对应的消费者端对第二服务端的业务消息进行消费。本申请实施例的同城多活数据中心下的消息处理方法通过自定义消息队列选择器能够将待发送的业务消息优先发送至与生产者端处于同一数据中心的服务端，降低了消息发送的延迟性，而在本地数据中心发生故障等情况时，又能够将待发送的业务消息直接发送至与生产者端处于同城数据中心的服务端，相比于现有方案中采用同城冷备集群进行接管的方式来说，处理效率更高，且同城多活的模式提高了集群资源利用率，降低了业务处理风险。

附图说明

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

图1为现有的一种基于RocketMQ消息队列搭建的分布式数据中心系统的系统架构示意图；

图2为本申请实施例一种RocketMQ消息队列集群的系统架构示意图；

图3为本申请实施例一种同城多活数据中心下的消息处理方法的流程示意图；

图4为本申请实施例一种同城多活数据中心下的消息处理装置的结构示意图；

图5为本申请实施例中一种电子设备的结构示意图。

具体实施方式

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

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

现有技术中使用较多的消息队列有ActiveMQ，RabbitMQ，Kafka，RocketMQ等，为了便于理解，下述各实施例均以RocketMQ消息队列为例进行阐述，但需要注意的是，不应当以此对本申请的保护范围造成不利限定。

RocketMQ(Rocket Message Queue)是一款分布式消息中间件，是一个采用Java语言开发的分布式的消息系统，具有高性能、高可靠、高实时、分布式的特点，被广泛应用在各种分布式系统架构中。

如图1所示，提供了现有的一种基于RocketMQ消息队列搭建的分布式数据中心系统的系统架构示意图，该分布式数据中心系统包括预先搭建的一套同城冷备模式的RocketMQ消息队列集群，一般情况下由主数据中心对外提供服务，当主数据中心的RocketMQ消息队列集群故障时，启用备用数据中心的RocketMQ消息队列集群接管服务。

然而，该方案存在如下问题：

1)资源利用不充分：由于一般情况下都是由主数据中心对外提供服务，备用数据中心的RocketMQ消息队列集群可能大多数情况下未提供服务，这将导致这部分资源得不到充分利用；

2)故障隔离时间长：当主数据中心的RocketMQ消息队列集群故障后，需要拉起备用数据中心的RocketMQ消息队列集群对外提供服务，一般情况下这个过程可能需要数分钟左右，在高并发等业务场景下，将会造成较大的交易风险。

基于此，如图2所示，提供了本申请实施例一种RocketMQ消息队列集群的系统架构示意图。RocketMQ消息队列集群主要包括生产者端(Producer)、消费者端(Consumer)、消息处理服务端(Broker)和配置信息服务端(NameServer)，生产者端和消费者端可以看作是RocketMQ消息队列中的客户端(Client)，Broker和NameServer可以看作是RocketMQ消息队列中的服务端(Server)。Broker和NameServer都可以以集群方式跨数据中心进行部署。

生产者端主要用于生产消息，并将消息发送给服务端的Broker节点进行消息存储或者中转，消费者端则主要用于从Broker节点获取消息或者接收Broker节点发送过来的消息，并对消息进行消费。Broker节点一般可以分为主节点(Master)和从节点(Slave)，每个Broker节点都会与NameServer集群中的所有节点建立长连接，并将Broker节点的信息以及Topic消息队列注册到所有NameServer节点中，Topic消息队列可以理解为是RocketMQ中的一个逻辑消息组织形式，一般情况下一类业务消息会申请一个Topic消息队列来实现业务之间隔离，所有的业务消息都要写到Topic消息队列中。NameServer可以看作是一个无状态的名称服务，每一个Broker节点启动的时候都会向所有的NameServer节点注册，除了接收Broker节点的注册，还可以接收客户端的路由请求并返回路由信息等。

如图2所示，在正常情况下，数据中心10和数据中心11中的服务端集群同时对外提供服务，相比于现有的同城冷备模式，保证了集群资源的充分利用。而当数据中心中的服务端集群发生故障时，将会由数据中心10的同城数据中心即数据中心11直接来接管数据中心10的工作，避免了对实际业务造成的影响，降低了高并发业务场景下的交易风险。

具体地，本申请实施例提供了一种同城多活数据中心下的消息处理方法，由消息队列集群中的生产者端执行，如图3所示，提供了本申请实施例一种同城多活数据中心下的消息处理方法的流程示意图，所述方法至少包括如下的步骤S310至步骤S330：

步骤S310，确定待发送的业务消息。

本申请实施例的同城多活数据中心下的消息处理方法可以由上述RocketMQ消息队列集群中的生产者端来执行，在进行消息处理时，生产者端可以先确定当前待发送的业务消息，这里的业务消息可以理解为是生产者端产生的各种业务请求。

步骤S320，根据所述待发送的业务消息，通过自定义消息队列选择器获取消息队列的路由信息。

在确定了待发送的业务消息后，需要进一步确定将待发送的业务消息发送到哪个服务端的消息队列中进行存储或中转，因此这里可以利用自定义消息队列选择器获取服务端如Broker节点的路由信息，这里的路由信息可以是本地数据中心即当前生产者端所在的数据中心所对应的服务端标识信息，也可以是同城数据中心对应的服务端标识信息。

步骤S330，根据所述消息队列的路由信息，将所述待发送的业务消息发送至与所述生产者端处于同一数据中心的第一服务端，以使所述第一服务端对应的消费者端对所述第一服务端的业务消息进行消费；或者，根据所述消息队列的路由信息，将所述待发送的业务消息发送至与所述生产者端处于同城数据中心的第二服务端，以使所述第二服务端对应的消费者端对所述第二服务端的业务消息进行消费。

在得到上述消息队列的路由信息后，如果该路由信息是本地数据中心所对应的服务端标识信息，则可以直接将待发送的业务消息发送至本地数据中心所对应的第一服务端中，如果该路由信息是同城数据中心所对应的服务端标识信息，则可以直接将待发送的业务消息发送至同城数据中心所对应的第二服务端中。因此在上述同城多活数据中心的模式下，当在本地数据中心发生故障等情况时，本地数据中心的业务消息可以直接发送至同城数据中心进行处理，提高了集群资源利用率，降低了业务处理风险。

本申请实施例的同城多活数据中心下的消息处理方法基于消息队列来实现，通过自定义消息队列选择器能够将待发送的业务消息优先发送至与生产者端处于同一数据中心的服务端，降低了消息发送的延迟性。在本地数据中心发生故障时，又能够将待发送的业务消息直接发送至与生产者端处于同城数据中心的服务端，相比于现有方案中采用同城冷备集群进行接管的方式来说，效率更高，且同城多活的模式提高了集群资源利用率，降低了业务处理风险。

在本申请的一个实施例中，所述根据所述消息队列的路由信息，将所述待发送的业务消息发送至与所述生产者端处于同一数据中心的第一服务端，以使所述第一服务端对应的消费者端对所述第一服务端的业务消息进行消费；或者，根据所述消息队列的路由信息，将所述待发送的业务消息发送至与所述生产者端处于同城数据中心的第二服务端，以使所述第二服务端对应的消费者端对所述第二服务端的业务消息进行消费包括：根据所述消息队列的路由信息，确定与所述生产者端处于同一数据中心的第一服务端是否存在Topic消息队列；若存在，则将所述待发送的业务消息发送至与所述生产者端处于同一数据中心的第一服务端；若不存在，则将所述待发送的业务消息发送至与所述生产者端处于同城数据中心的第二服务端。

一般情况下，本申请实施例的同城多活数据中心下的消息处理方法会将待发送的业务消息优先发送至与生产者端处于同一数据中心的第一服务端，这样可以避免跨数据中心网络请求的延时导致消息发送时间增加，进而提高消息发送效率。

如前所述，所有生产者端发送的业务消息都会写入到Broker的消息队列中，而实际场景下，一些Broker节点中可能没有创建Topic消息队列，因此本申请实施例在将待发送的业务消息发送至与生产者端处于同一数据中心的第一服务端时，可以先确定生产者端所在的本地数据中心的服务端中是否有Topic消息队列，如果有，则可以直接将待发送的业务消息发送至本地数据中心所在的第一服务端；如果没有，则可以将待发送的业务消息发送至与生产者端处于同城数据中心的第二服务端。

在本申请的一个实施例中，所述自定义消息队列选择器中维护有多个生产者端所在的数据中心的数据中心标识，所述若不存在，则将所述待发送的业务消息发送至与所述生产者端处于同城数据中心的第二服务端包括：通过所述自定义消息队列选择器查询与所述生产者端所在的数据中心的数据中心标识相对应的同城数据中心标识；根据所述同城数据中心标识，将所述待发送的业务消息发送至所述同城数据中心标识对应的第二服务端。

本申请实施例的自定义消息队列选择器存储有各个生产者端所在的数据中心的数据中心标识，在确定要将待发送的业务消息发送至与生产者端处于同城数据中心的第二服务端时，可以先确定当前的生产者端所在的数据中心的数据中心标识，然后在自定义消息队列选择器中查询与当前的生产者端所在的数据中心的数据中心标识相对应的同城数据中心标识，最后根据同城数据中心标识，将待发送的业务消息发送到同城数据中心标识对应的第二服务端，进而实现了跨数据中心的消息发送。

在本申请的一个实施例中，所述将所述待发送的业务消息发送至所述同城数据中心标识对应的第二服务端包括：根据所述消息队列的路由信息确定所述第二服务端是否存在Topic消息队列；若存在，则将所述待发送的业务消息发送至所述第二服务端；若不存在，则输出第一消息发送失败结果。

在将待发送的业务消息发送到同城数据中心标识对应的第二服务端后，同样可以先确定第二服务端中是否已经创建了Topic消息队列，如果已经有Topic消息队列，则可以直接将待发送的业务消息发送给第二服务端，如果没有，说明此时同城数据中心所对应的服务端也无法提供消息存储或者中转的功能，则输出第一消息发送失败结果，该结果用于表征由于本地数据中心和同城数据中心的服务端中均没有Topic消息队列而导致生产者端的业务消息没有成功发出。

在本申请的一个实施例中，所述消息队列集群包括消息处理服务集群，所述消息处理服务集群中包括多个跨数据中心部署的消息处理服务节点，所述第一服务端和所述第二服务端均是指所述消息处理服务集群中的各消息处理服务节点，所述消息处理服务节点的名称中携带有数据中心标识，所述根据所述消息队列的路由信息，将所述待发送的业务消息发送至与所述生产者端处于同一数据中心的第一服务端，以使所述第一服务端对应的消费者端对所述第一服务端的业务消息进行消费；或者，根据所述消息队列的路由信息，将所述待发送的业务消息发送至与所述生产者端处于同城数据中心的第二服务端，以使所述第二服务端对应的消费者端对所述第二服务端的业务消息进行消费包括：根据所述消息处理服务节点的名称中携带的数据中心标识以及所述生产者端所在的数据中心的数据中心标识，确定与所述生产者端处于同一数据中心的第一服务端或者与所述生产者端处于同城数据中心的第二服务端。

如前所述，本申请实施例的RocketMQ消息队列集群可以包括Broker集群，Broker集群中可以由多个跨数据中心部署的Broker节点构成，上述第一服务端和第二服务端都可以看作是一个Broker节点。为了便于实现同城多活模式下的跨数据中心的消息发送，这里还可以事先在Broker节点的名称设置有Broker节点所在的数据中心的数据中心标识。

在根据消息队列的路由信息进行业务消息的发送时，可以先根据生产者端所在的数据中心的数据中心标识确定生产者端当前所在的数据中心，然后再根据各Broker节点的名称中携带的数据中心标识确定与生产者端当前所在的数据中心处于同一数据中心的第一服务端，进而可以将业务消息发送给该第一服务端，或者确定出与生产者端处于同城数据中心的第二服务端，进而可以将业务消息发送给第二服务端。

在本申请的一个实施例中，所述消息队列集群包括配置信息服务集群，所述配置信息服务集群中包括多个跨数据中心部署的配置信息服务节点，所述通过自定义消息队列选择器获取消息队列的路由信息包括：通过所述自定义消息队列选择器，从所述配置信息服务节点中获取所述消息队列的路由信息。

如前所述，本申请实施例的RocketMQ消息队列集群还包括NameServer集群，NameServer集群可以由多个跨数据中心部署的NameServer节点构成，NameServer集群中维护了各个Broker节点的注册信息以及各个Broker节点定期上报的Topic消息队列等，因此NameServer集群也可以看作是一个路由注册中心。

基于此，本申请实施例的生产者端在通过自定义消息队列选择器获取消息队列的路由信息时，就可以从相应的NameServer节点中获取消息队列的路由信息，如Broker节点的名称及对应的Topic消息队列等信息。为了提高消息发送的效率，这里可以优先从与生产者端处于同一数据中心的NameServer节点中获取上述信息。

在本申请的一个实施例中，在将所述待发送的业务消息发送至与所述生产者端处于同一数据中心的第一服务端或者与所述生产者端处于同城数据中心的第二服务端之后，所述方法还包括：确定是否能够接收到所述第一服务端或者所述第二服务端返回的消息发送成功结果；若不能，则输出第二消息发送失败结果。

在实际应用场景下，可能会出现Broker节点发生故障的情况，当Broker节点发生故障时，Broker节点将无法再向NameServer节点上报Broker节点中的Topic消息队列，然而由于Topic消息队列一般是每隔一段时间上报一次，因此当Broker节点故障时，NameServer节点需要过一段时间才能觉察到，然后才能将该故障的Broker节点上对应的Topic消息队列从NameServer中清理掉，并对故障节点进行隔离，避免后续的业务消息再发送到该故障节点上。

这种情况下可能出现的问题是：Broker节点已经故障，而NameServer节点由于需要过一段时间才能觉察到，导致现在还没有清理掉相应的Topic消息队列，生产者端在从NameServer节点获取消息队列的路由信息时，仍然会获取到已故障的Broker节点对应的Topic消息队列，进而就可能会继续将业务消息发送到已故障的Broker节点上，但显然此时该Broker节点已经无法响应，进而导致出现了业务消息已经发出但没有成功写入Topic消息队列的情况。

因此本申请实施例在将待发送的业务消息发送到与生产者端处于同一数据中心的第一服务端或者与生产者端处于同城数据中心的第二服务端后，还进一步判断了是否能够接收到第一服务端或者第二服务端返回的消息发送成功的结果，如果不能，则输出第二消息发送失败结果，该结果用于表征由于Broker节点故障而导致业务消息没有成功写入到Topic消息队列中。

在本申请的一个实施例中，在输出第二消息发送失败结果之后，所述方法还包括：调用自定义消息重试接口；通过所述自定义消息重试接口，对所述第二消息发送失败结果对应的业务信息重新发送。

针对上述由于Broker节点故障而导致业务消息没有成功写入到Topic消息队列的情况，为了避免业务损失，可以基于消息重试机制将发送失败的业务消息重新发送，以尽可能使业务消息发送成功。

然而现有的RocketMQ消息队列在使用MessageQueueSelector接口进行发送时，并不支持消息重试的功能。因此本申请实施例在现有的MessageQueueSelector接口的基础上，进一步开发了自定义消息重试接口，通过调用该自定义消息重试接口，可以将上述第二消息发送失败结果对应的业务信息重新发送。

上述第二消息发送失败结果中具体可以包含有待发送的业务消息及上次发送失败的Broker节点的名称，这样自定义消息重试接口在根据第二消息发送失败结果重新发送业务消息时，就可以避开上次已故障的Broker节点，以提高消息发送成功的概率。

在本申请的一个实施例中，所述自定义消息重试接口通过如下方式得到：自定义生产者参数，并将用于发送业务消息的API接口进行包装；将包装后的API接口与所述生产者端常用的API接口对齐，得到所述自定义消息重试接口。

在设置自定义消息重试接口时，可以先自定义生产者参数，然后将用于发送业务消息的API接口进行包装，与生产者端常用的API接口对齐，以提供消息重试功能。这里的“对齐”可以理解为是将自定义消息重试接口对外暴露的接口形式与生产者端常用的API接口的形式保持一致，这样当生产者端接入RocketMQ消息队列集群中时，只需要修改生产者参数即可，无需做其他的变动，简化了生产者端的操作。

在本申请的一个实施例中，在确定待发送的业务消息之后，所述方法还包括：在所述待发送的业务消息的Tag标签中设置数据中心标识，所述数据中心标识用于表征对业务消息进行消费的消费者端所在的数据中心的标识，以使所述消费者端根据所述Tag标签中设置数据中心标识对业务消息进行消费。

实际应用场景下，Topic消息队列中的业务消息最终是要被消费者端消费的，由于本申请实施例提供的消息处理方式针对的是同城多活数据中心，考虑到业务消息可能会发送到同城数据中心的服务端，这时就需要结合实际的业务场景进一步确定该业务消息是否必须要被与生产者端处于同一数据中心的消费者端进行消费，还是也可以被与生产者端处于同城数据中心的消费者端进行消费。

通常不同的业务类型的业务期望结果可能不一样，当业务方能够接受这条业务消息被同城数据中心的消费者端消费时，则生产者端和消费者端无需做额外的处理，使用原有的方式进行消费即可。而当业务方希望这条业务消息被本地数据中心的消费者端消费时，则生产者端和消费者端可以做一些适配工作。

具体地，本申请实施例的生产者端在发送业务消息，可以在待发送的业务消息的Tag标签中增加数据中心标识，该数据中心标识是指可以消费该条业务消息的消费者端所在的数据中心的标识，这样无论业务消息是发送到本地数据中心的服务端还是同城数据中心的服务端，消费者端都可以根据业务消息中携带的数据中心标识对相应的业务消息进行消费，满足了不同业务方的消费需求。

举例说明，将发送到数据中心10的业务消息的Tag标签设置为“10-A”，发送到数据中心11的业务消息的Tag标签设置为“11-A”。消费者订阅消息时也保持与本地数据中心的生产者端设置的Tag标签一致，即数据中心10的业务消息的Tag标签设置为“10-A”，数据中心11的业务消息的Tag标签设置为“11-A”，这样在当业务消息发送到同城数据中心时，由于业务消息的Tag标签中已经加上了本地数据中心的标识了，因此该条业务消息最终将被本地数据中心的消费者端消费。

需要说明的是，本申请实施例的消费者端在消费业务信息时，可以是主动从Broker节点的Topic消息队列中获取所需的业务消息进行消费，也可以是由Broker节点根据消费者端的订阅信息将相应的业务消息发送给消费者端进行消费。当然，消费者端具体如何消费业务消息，本领域技术人员可根据实际情况灵活设置，在此不作具体限定。

在本申请的一个实施例中，所述消息队列集群包括配置信息服务集群和消息处理服务集群，所述配置信息服务集群和消息处理服务集群通过如下方式得到：搭建所述配置信息服务集群，所述配置信息服务集群中包括多个跨数据中心部署的配置信息服务节点；搭建所述消息处理服务集群，所述消息处理服务r集群中包括多个跨数据中心部署的消息处理服务节点；将各消息处理服务节点的名称以及各消息处理服务节点上创建的Topic消息队列在所述配置信息服务集群中的各配置信息服务节点中均进行注册，以完成所述配置信息服务集群和所述消息处理服务集群的搭建。

本申请实施例在进行跨数据中心的业务消息发送之前，事先搭建了RocketMQ消息队列集群，用于实现同城多活的能力，具体可以包括NameServer集群和Broker集群这些服务端集群的搭建。

具体实施时，可以先搭建NameServer集群，NameServer集群由本地数据中心和同城数据中心的多个NameServer服务节点构成，NameServer节点的具体数量可以根据实际需求适当调整，在此不作具体限定。这样当本地数据中心的NameServer节点故障时，还可以由其他同城数据中心的NameServer节点提供服务。

之后可以搭建Broker集群，Broker集群由本地数据中心和同城数据中心的多个Broker节点构成，各个Broker节点均向所有的NameServer节点进行注册并定期上报Broker节点中的Topic消息队列的状态，Broker节点的数量同样可以根据实际需求进行适当调整。

为了便于对本申请上述各实施例的理解，提供了一种实际应用场景下的同城多活数据中心下的消息处理流程，这里以转账交易场景为例，假设用户A拟向用户B转账10元，则用户A在其所在的终端会生成一条转账交易请求，该转账交易请求是指将用户A账户中的10元转给用户B的账户的请求，然后用户A所在的终端会将该转账交易请求优先写到本地数据中心的Broker节点中的Topic消息队列中，如果本地数据中心发生故障或者没有Topic消息队列，则会写到同城数据中心的Broker节点中的Topic消息队列中。

之后Broker节点会将该转账交易请求推送给转账系统，使得转账系统可以根据该转账交易请求从用户A的账户扣减10元，扣减成功后，会在用户B的账户中增加10元，如果增加成功，即完成一次转账交易。

本申请实施例还提供了一种同城多活数据中心下的消息处理装置400，应用于消息队列集群中的生产者端，如图4所示，提供了本申请实施例一种同城多活数据中心下的消息处理装置的结构示意图，所述装置400包括：第一确定单元410、获取单元420及发送单元430，其中：

第一确定单元410，用于确定待发送的业务消息；

获取单元420，用于根据所述待发送的业务消息，通过自定义消息队列选择器获取消息队列的路由信息；

发送单元430，用于根据所述消息队列的路由信息，将所述待发送的业务消息发送至与所述生产者端处于同一数据中心的第一服务端，以使所述第一服务端对应的消费者端对所述第一服务端的业务消息进行消费；或者，根据所述消息队列的路由信息，将所述待发送的业务消息发送至与所述生产者端处于同城数据中心的第二服务端，以使所述第二服务端对应的消费者端对所述第二服务端的业务消息进行消费。

在本申请的一个实施例中，所述发送单元430具体用于：根据所述消息队列的路由信息，确定与所述生产者端处于同一数据中心的第一服务端是否存在Topic消息队列；若存在，则将所述待发送的业务消息发送至与所述生产者端处于同一数据中心的第一服务端；若不存在，则将所述待发送的业务消息发送至与所述生产者端处于同城数据中心的第二服务端。

在本申请的一个实施例中，所述自定义消息队列选择器中维护有多个生产者端所在的数据中心的数据中心标识，所述发送单元430具体用于：通过所述自定义消息队列选择器查询与所述生产者端所在的数据中心的数据中心标识相对应的同城数据中心标识；根据所述同城数据中心标识，将所述待发送的业务消息发送至所述同城数据中心标识对应的第二服务端。

在本申请的一个实施例中，所述发送单元430具体用于：根据所述消息队列的路由信息确定所述第二服务端是否存在Topic消息队列；若存在，则将所述待发送的业务消息发送至所述第二服务端；若不存在，则输出第一消息发送失败结果。

在本申请的一个实施例中，所述RocketMQ消息队列集群包括消息处理服务集群，所述消息处理服务集群中包括多个跨数据中心部署的消息处理服务节点，所述第一服务端和所述第二服务端均是指所述消息处理服务集群中的各消息处理服务节点，所述消息处理服务节点的名称中携带有数据中心标识，所述发送单元430具体用于：根据所述消息处理服务节点的名称中携带的数据中心标识以及所述生产者端所在的数据中心的数据中心标识，确定与所述生产者端处于同一数据中心的第一服务端或者与所述生产者端处于同城数据中心的第二服务端。

在本申请的一个实施例中，所述装置还包括：第二确定单元，用于确定是否能够接收到所述第一服务端或者所述第二服务端返回的消息发送成功结果；第一输出单元，用于若不能，则输出第二消息发送失败结果。

在本申请的一个实施例中，所述装置还包括：调用单元，用于调用自定义消息重试接口；重试单元，用于通过所述自定义消息重试接口，对所述第二消息发送失败结果对应的业务信息重新发送。

在本申请的一个实施例中，所述自定义消息重试接口通过如下方式得到：自定义生产者参数，并将用于发送业务消息的API接口进行包装；将包装后的API接口与所述生产者端常用的API接口对齐，得到所述自定义消息重试接口。

在本申请的一个实施例中，所述RocketMQ消息队列集群包括配置信息服务集群，所述配置信息服务集群中包括多个跨数据中心部署的配置信息服务节点，所述获取单元420具体用于：通过所述自定义消息队列选择器，从所述配置信息服务节点中获取所述消息队列的路由信息。

在本申请的一个实施例中，所述装置还包括：设置单元，用于在所述待发送的业务消息的Tag标签中设置数据中心标识，所述数据中心标识用于表征对业务消息进行消费的消费者端所在的数据中心的标识，以使所述消费者端根据所述Tag标签中设置数据中心标识对业务消息进行消费。

在本申请的一个实施例中，所述RocketMQ消息队列集群包括配置信息服务集群和消息处理服务集群，所述配置信息服务集群和消息处理服务集群通过如下方式得到：搭建所述配置信息服务集群，所述配置信息服务集群中包括多个跨数据中心部署的配置信息服务节点；搭建所述消息处理服务集群，所述消息处理服务集群中包括多个跨数据中心部署的消息处理服务节点；将各消息处理服务节点的名称以及各消息处理服务节点上创建的Topic消息队列在所述配置信息服务集群中的各配置信息服务节点中均进行注册，以完成所述配置信息服务集群和所述消息处理服务集群的搭建。

能够理解，上述同城多活数据中心下的消息处理装置，能够实现前述实施例中提供的由消息队列集群中的生产者端执行的同城多活数据中心下的消息处理方法的各个步骤，关于同城多活数据中心下的消息处理方法的相关阐释均适用于同城多活数据中心下的消息处理装置，此处不再赘述。

图5是本申请的一个实施例电子设备的结构示意图。请参考图5，在硬件层面，该电子设备包括处理器，可选地还包括内部总线、网络接口、存储器。其中，存储器可能包含内存，例如高速随机存取存储器(Random-Access Memory，RAM)，也可能还包括非易失性存储器(non-volatile memory)，例如至少1个磁盘存储器等。当然，该电子设备还可能包括其他业务所需要的硬件。

处理器、网络接口和存储器可以通过内部总线相互连接，该内部总线可以是ISA(Industry Standard Architecture，工业标准体系结构)总线、PCI(PeripheralComponent Interconnect，外设部件互连标准)总线或EISA(Extended Industry StandardArchitecture，扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图5中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

存储器，用于存放程序。具体地，程序可以包括程序代码，所述程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器，并向处理器提供指令和数据。

处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成同城多活数据中心下的消息处理装置。处理器，执行存储器所存放的程序，并具体用于执行以下操作：

确定待发送的业务消息；

根据所述待发送的业务消息，通过自定义消息队列选择器获取消息队列的路由信息；

根据所述消息队列的路由信息，将所述待发送的业务消息发送至与所述生产者端处于同一数据中心的第一服务端，以使所述第一服务端对应的消费者端对所述第一服务端的业务消息进行消费；或者，根据所述消息队列的路由信息，将所述待发送的业务消息发送至与所述生产者端处于同城数据中心的第二服务端，以使所述第二服务端对应的消费者端对所述第二服务端的业务消息进行消费。

上述如本申请图4所示实施例揭示的同城多活数据中心下的消息处理装置执行的方法可以应用于处理器中，或者由处理器实现。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器，包括中央处理器(CentralProcessing Unit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific IntegratedCircuit，ASIC)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。

该电子设备还可执行图4中同城多活数据中心下的消息处理装置执行的方法，并实现同城多活数据中心下的消息处理装置在图4所示实施例的功能，本申请实施例在此不再赘述。

本申请实施例还提出了一种计算机可读存储介质，该计算机可读存储介质存储一个或多个程序，该一个或多个程序包括指令，该指令当被包括多个应用程序的电子设备执行时，能够使该电子设备执行图4所示实施例中同城多活数据中心下的消息处理装置执行的方法，并具体用于执行：

确定待发送的业务消息；

根据所述待发送的业务消息，通过自定义消息队列选择器获取消息队列的路由信息；

根据所述消息队列的路由信息，将所述待发送的业务消息发送至与所述生产者端处于同一数据中心的第一服务端，以使所述第一服务端对应的消费者端对所述第一服务端的业务消息进行消费；或者，根据所述消息队列的路由信息，将所述待发送的业务消息发送至与所述生产者端处于同城数据中心的第二服务端，以使所述第二服务端对应的消费者端对所述第二服务端的业务消息进行消费。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

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

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

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

Claims (14)

1.一种同城多活数据中心下的消息处理方法，由消息队列集群中的生产者端执行，其中，所述方法包括：

确定待发送的业务消息；

根据所述待发送的业务消息，通过自定义消息队列选择器获取消息队列的路由信息；

根据所述消息队列的路由信息，将所述待发送的业务消息发送至与所述生产者端处于同一数据中心的第一服务端，以使所述第一服务端对应的消费者端对所述第一服务端的业务消息进行消费；或者，根据所述消息队列的路由信息，将所述待发送的业务消息发送至与所述生产者端处于同城数据中心的第二服务端，以使所述第二服务端对应的消费者端对所述第二服务端的业务消息进行消费。

2.如权利要求1所述方法，其中，所述根据所述消息队列的路由信息，将所述待发送的业务消息发送至与所述生产者端处于同一数据中心的第一服务端，以使所述第一服务端对应的消费者端对所述第一服务端的业务消息进行消费；或者，根据所述消息队列的路由信息，将所述待发送的业务消息发送至与所述生产者端处于同城数据中心的第二服务端，以使所述第二服务端对应的消费者端对所述第二服务端的业务消息进行消费包括：

根据所述消息队列的路由信息，确定与所述生产者端处于同一数据中心的第一服务端是否存在Topic消息队列；

若存在，则将所述待发送的业务消息发送至与所述生产者端处于同一数据中心的第一服务端；

若不存在，则将所述待发送的业务消息发送至与所述生产者端处于同城数据中心的第二服务端。

3.如权利要求2所述方法，其中，所述自定义消息队列选择器中维护有多个生产者端所在的数据中心的数据中心标识，所述若不存在，则将所述待发送的业务消息发送至与所述生产者端处于同城数据中心的第二服务端包括：

通过所述自定义消息队列选择器查询与所述生产者端所在的数据中心的数据中心标识相对应的同城数据中心标识；

根据所述同城数据中心标识，将所述待发送的业务消息发送至所述同城数据中心标识对应的第二服务端。

4.如权利要求2所述方法，其中，所述将所述待发送的业务消息发送至所述同城数据中心标识对应的第二服务端包括：

根据所述消息队列的路由信息确定所述第二服务端是否存在Topic消息队列；

若存在，则将所述待发送的业务消息发送至所述第二服务端；

若不存在，则输出第一消息发送失败结果。

5.如权利要求3所述方法，其中，所述消息队列集群包括消息处理服务集群，所述消息处理服务集群中包括多个跨数据中心部署的消息处理服务节点，所述第一服务端和所述第二服务端均是指所述消息处理服务集群中的任意一个消息处理服务节点，所述消息处理服务节点的名称中携带有数据中心标识，

所述根据所述消息队列的路由信息，将所述待发送的业务消息发送至与所述生产者端处于同一数据中心的第一服务端，以使所述第一服务端对应的消费者端对所述第一服务端的业务消息进行消费；或者，根据所述消息队列的路由信息，将所述待发送的业务消息发送至与所述生产者端处于同城数据中心的第二服务端，以使所述第二服务端对应的消费者端对所述第二服务端的业务消息进行消费包括：

根据所述消息处理服务节点的名称中携带的数据中心标识以及所述生产者端所在的数据中心的数据中心标识，确定与所述生产者端处于同一数据中心的第一服务端或者与所述生产者端处于同城数据中心的第二服务端。

6.如权利要求1所述方法，其中，在将所述待发送的业务消息发送至与所述生产者端处于同一数据中心的第一服务端或者与所述生产者端处于同城数据中心的第二服务端之后，所述方法还包括：

确定是否能够接收到所述第一服务端或者所述第二服务端返回的消息发送成功结果；

若不能，则输出第二消息发送失败结果。

7.如权利要求6所述方法，其中，在输出第二消息发送失败结果之后，所述方法还包括：

调用自定义消息重试接口；

通过所述自定义消息重试接口，对所述第二消息发送失败结果对应的业务信息重新发送。

8.如权利要求7所述方法，其中，所述自定义消息重试接口通过如下方式得到：

自定义生产者参数，并将用于发送业务消息的API接口进行包装；

将包装后的API接口与所述生产者端常用的API接口对齐，得到所述自定义消息重试接口。

9.如权利要求1所述方法，其中，所述消息队列集群包括配置信息服务集群，所述配置信息服务集群中包括多个跨数据中心部署的配置信息服务节点，所述通过自定义消息队列选择器获取消息队列的路由信息包括：

通过所述自定义消息队列选择器，从所述配置信息服务节点中获取所述消息队列的路由信息。

10.如权利要求1所述方法，其中，在确定待发送的业务消息之后，所述方法还包括：

在所述待发送的业务消息的Tag标签中设置数据中心标识，所述数据中心标识用于表征对业务消息进行消费的消费者端所在的数据中心的标识，以使所述消费者端根据所述Tag标签中设置数据中心标识对业务消息进行消费。

11.如权利要求1所述方法，其中，所述消息队列集群包括配置信息服务集群和消息处理服务集群，所述配置信息服务集群和消息处理服务集群通过如下方式得到：

搭建所述配置信息服务集群，所述配置信息服务集群中包括多个跨数据中心部署的配置信息服务节点；

搭建所述消息处理服务集群，所述消息处理服务集群中包括多个跨数据中心部署的消息处理服务节点；

将各消息处理服务节点的名称以及各消息处理服务节点上创建的Topic消息队列在所述配置信息服务集群中的各配置信息服务节点中均进行注册，以完成所述配置信息服务集群和所述消息处理服务集群的搭建。

12.一种同城多活数据中心下的消息处理装置，应用于消息队列集群中的生产者端，其中，所述装置用于实现权利要求1～11之任一所述方法。

13.一种电子设备，包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行所述权利要求1～11之任一所述方法。

14.一种计算机可读存储介质，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的电子设备执行时，使得所述电子设备执行所述权利要求1～11之任一所述方法。

Images