CN115866039A - 消息处理方法、装置、电子设备及存储介质 - Google Patents

Abstract

本公开关于消息处理方法、装置、电子设备及存储介质，涉及消息中间件领域，方法包括：获取目标时间段内的业务消息集和至少两种消息队列在所述目标时间段内各自对应的消息量比例；根据所述各自对应的消息量比例，从所述业务消息集中确定所述至少两种消息队列各自对应的业务消息子集；对目标消息队列中的目标消息进行分布式锁创建处理，得到创建结果；所述目标消息队列为任一消息队列，所述目标消息为所述目标消息队列对应的业务消息子集中的任一子业务消息；在所述创建结果指示创建成功的情况下，执行对所述目标消息的处理。利用本公开实施例提供的技术方案可以通过多种消息队列提高消息传输机制的可用性和吞吐量，保证消息传输和处理的可靠准确。

Description

消息处理方法、装置、电子设备及存储介质

技术领域

本公开涉及消息中间件技术领域，尤其涉及消息处理方法、装置、电子设备及存储介质。

背景技术

在分布式业务系统中，常常利用消息队列(也可称为消息中间件)实现多个业务子系统之间的消息传输。但是高并发的业务场景以及业务系统的不断扩展容易造成消息队列中消息传输的阻塞或延迟，效率低下。因此有必要对分布式业务系统中所使用的消息队列进行升级或改造以满足更高的可用性和更高消息吞吐性能的需求，同时还要保证对消息传输和处理的可靠与准确。

发明内容

本公开提供消息处理方法、装置、电子设备及存储介质，以至少解决相关技术中高并发的业务场景以及业务系统的不断扩展容易造成消息队列中消息传输的阻塞或延迟，效率低下的问题。本公开的技术方案如下：

根据本公开实施例的第一方面，提供一种消息处理方法，包括：

获取目标时间段内的业务消息集，以及至少两种消息队列在所述目标时间段内各自对应的消息量比例；

根据所述各自对应的消息量比例，从所述业务消息集中确定所述至少两种消息队列各自对应的业务消息子集；

对目标消息队列中的目标消息进行分布式锁创建处理，得到创建结果；所述目标消息队列为任一消息队列，所述目标消息为所述目标消息队列对应的业务消息子集中的任一子业务消息；

在所述创建结果指示创建成功的情况下，执行对所述目标消息的处理。

可选的，所述至少两种消息队列包括第一消息队列和第二消息队列，所述根据所述各自对应的消息量比例，从所述业务消息集中确定所述至少两种消息队列各自对应的业务消息子集，包括：

根据所述各自对应的消息量比例，从所述业务消息集中确定第一业务消息子集和第二业务消息子集；

在所述目标时间段处于消息队列迁移的第一阶段中的情况下，所述第一业务消息子集对应所述业务消息集中全部的业务消息，所述第二业务消息子集对应所述业务消息集中局部的业务消息；

在所述目标时间段处于消息队列迁移的第二阶段中的情况下，所述第一业务消息子集对应所述业务消息集中局部的业务消息，所述第二业务消息子集对应所述业务消息集中全部的业务消息；

所述第一阶段在所述第二阶段之前。

可选的，所述方法还包括：

当所述第一业务消息子集的消息量减少至零时，断开与所述第一消息队列的通信连接。

可选的，所述对目标消息队列中的目标消息进行分布式锁创建处理，得到创建结果，包括：

确定所述目标消息的目标标识；

基于所述目标标识，创建与所述目标消息对应的分布式锁，得到创建结果，所述创建结果指示与所述目标消息对应的分布式锁创建成功或失败。

可选的，所述方法还包括：

在所述创建结果指示创建失败的情况下，放弃对所述目标消息的处理。

可选的，所述在所述创建结果指示创建成功的情况下，执行对所述目标消息的处理，包括：

在所述创建结果指示创建成功的情况下，与所述目标消息队列对应的目标消费实例根据所述目标消息，更新业务数据。

可选的，所述业务数据包括业务日志数据和所述根据所述目标消息，更新业务数据，包括：

确定所述目标消息的目标日志索引标识；

在所述业务日志数据中不存在所述目标日志索引标识的情况下，将所述目标消息添加至所述业务日志数据中，并更新所述业务日志数据。

可选的，所述业务数据包括业务统计数据，所述根据所述目标消息，更新业务数据，还包括：

在所述目标消费实例具有重试机制的情况下，确定与所述目标消息对应的目标统计标识；

在所述目标统计标识指示所述目标消息未被统计过的情况下，根据所述目标消息更新所述业务统计数据。

可选的，在所述执行对所述目标消息的处理之后，所述方法还包括：

在所述目标消息的处理状态为成功、失败或超时的情况下，释放所述分布式锁。

根据本公开实施例的第二方面，提供一种消息处理装置，包括：

获取模块，被配置为执行获取目标时间段内的业务消息集，以及至少两种消息队列在所述目标时间段内各自对应的消息量比例；

子集确定模块，被配置为执行根据所述各自对应的消息量比例，从所述业务消息集中确定所述至少两种消息队列各自对应的业务消息子集；

锁模块，被配置为执行对目标消息队列中的目标消息进行分布式锁创建处理，得到创建结果；所述目标消息队列为任一消息队列，所述目标消息为所述目标消息队列对应的业务消息子集中的任一子业务消息；

消息处理模块，被配置为执行在所述创建结果指示创建成功的情况下，执行对所述目标消息的处理。

可选的，所述至少两种消息队列包括第一消息队列和第二消息队列，所述子集确定模块包括：

子集确定单元，被配置为执行根据所述各自对应的消息量比例，从所述业务消息集中确定第一业务消息子集和第二业务消息子集；

在所述目标时间段处于消息队列迁移的第一阶段中的情况下，所述第一业务消息子集对应所述业务消息集中全部的业务消息，所述第二业务消息子集对应所述业务消息集中局部的业务消息；

在所述目标时间段处于消息队列迁移的第二阶段中的情况下，所述第一业务消息子集对应所述业务消息集中局部的业务消息，所述第二业务消息子集对应所述业务消息集中全部的业务消息；

所述第一阶段在所述第二阶段之前。

可选的，所述子集确定单元还包括：

切换子单元，被配置为执行当所述第一业务消息子集的消息量减少至零时，断开与所述第一消息队列的通信连接。

可选的，所述锁模块包括：

标识确定单元，被配置为执行确定所述目标消息的目标标识；

锁创建单元，被配置为执行基于所述目标标识，创建与所述目标消息对应的分布式锁，得到创建结果，所述创建结果指示与所述目标消息对应的分布式锁创建成功或失败。

可选的，所述装置还包括：

丢弃模块，被配置为执行在所述创建结果指示创建失败的情况下，放弃对所述目标消息的处理。

可选的，所述消息处理模块包括：

业务更新单元，被配置为执行在所述创建结果指示创建成功的情况下，与所述目标消息队列对应的目标消费实例根据所述目标消息，更新业务数据。

可选的，所述业务更新单元包括：

日志标识确定子单元，被配置为执行确定所述目标消息的目标日志索引标识；

业务日志数据更新子单元，被配置为执行在所述业务日志数据中不存在所述目标日志索引标识的情况下，将所述目标消息添加至所述业务日志数据中，并更新所述业务日志数据。

可选的，所述业务更新单元还包括：

统计标识确定子单元，被配置为执行在所述目标消费实例具有重试机制的情况下，确定与所述目标消息对应的目标统计标识；

业务统计数据更新子单元，被配置为执行在所述目标统计标识指示所述目标消息未被统计过的情况下，根据所述目标消息更新所述业务统计数据。

可选的，所述装置还包括：

锁释放单元，被配置为执行在所述目标消息的处理状态为成功、失败或超时的情况下，释放所述分布式锁。

根据本公开实施例的第三方面，提供一种电子设备，包括：处理器；用于存储所述处理器可执行指令的存储器；其中，所述处理器被配置为执行所述指令，以实现本公开实施例第一方面中任一项所述的消息处理方法。

根据本公开实施例的第四方面，提供一种计算机可读存储介质，当所述计算机可读存储介质中的指令由电子设备的处理器执行时，使得所述电子设备能够执行如本公开实施例第一方面中任一项所述的消息处理方法。

根据本公开实施例的第五方面，提供一种计算机程序产品，包括计算机指令，所述计算机指令被处理器执行时实现如本公开实施例第一方面中任一项所述的消息处理方法。

本公开实施例提供的技术方案至少带来以下有益效果：本公开实施例所提供的技术方案中将目标时间段内的业务消息集，按照至少两种消息队列在目标时间段内各自对应的消息量比例，分配给各消息队列，每种消息队列接收到各自对应的业务消息子集并进行传输；对于目标消息队列中的目标消息进行分布式锁创建处理，得到创建结果，其中目标消息队列是至少两种消息队列中的任一消息队列，目标消息是目标消息队列对应的业务消息子集中的任一子业务消息；在创建结果指示分布式锁创建成功的情况下，执行对目标消息的处理。本公开实施例所提供的技术方案通过多种消息队列协同工作以对消息进行接收和传输，缓解了高并发业务场景或分布式业务系统中的消息传输压力，提高了消息传输机制的可用性和消息吞吐量，从而可以提高消息传输的效率；并且可以通过各消息队列在不同时间段内对应的消息量比例调整各消息队列所要接收并传输的消息量，更好地实现多种消息队列的协同合作，避免出现消息队列的阻塞，提高了每个消息队列的可用性；通过消息队列在不同时间段内各自对应的消息量比例进行业务消息的分配，各消息队列对应的业务消息子集之和覆盖全部的业务消息集，可以实现业务消息的不丢失，以及对各消息队列对应的业务消息子集中的任一子业务消息创建分布式锁，在创建成功的情况才执行处理，可以保证业务消息集中的业务消息不会被重复处理，保证消息处理的可靠和准确。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理，并不构成对本公开的不当限定。

图1是根据一示例性实施例示出的一种消息处理方法的实施环境的示意图；

图2是根据一示例性实施例示出的一种消息处理方法的流程图；

图3是根据一示例性实施例示出的一种应用于消息队列迁移过程中不同时间段内消息队列的消息量比例示意图；

图4是根据一示例性实施例示出的一种在分布式锁创建成功的情况下消息处理的流程图；

图5是根据一示例性实施例示出的一种应用于消息队列迁移过程中消息处理方法的完整流程示意图；

图6是根据一示例性实施例示出的一种消息处理装置的框图；

图7是根据一示例性实施例示出的一种用于实现消息处理方法的电子设备的框图。

具体实施方式

为了使本领域普通人员更好地理解本公开的技术方案，下面将结合附图，对本公开实施例中的技术方案进行清楚、完整地描述。

需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

需要说明的是，本公开所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于展示的数据、分析的数据等)，均为经用户授权或者经过各方充分授权的信息和数据。

请参阅图1，图1是根据一示例性实施例示出的一种消息处理方法的应用环境示意图。如图1所示，该应用环境可以包括消息生产服务器100、消息队列服务器200、消息队列服务器300、消息消费服务器400、消息消费服务器500、锁竞争服务器600。

在实际应用中，分布式业务系统需要将业务子系统-1所生成的业务消息通过消息队列传输至业务子系统-2以使业务子系统-2对业务消息进行相应的业务处理。

消息生产服务器100为业务子系统-1中的服务器，用于生成业务子系统-1在相应业务处理过程中的业务消息。

消息队列服务器200和消息队列服务器300对应两种不同类型的消息队列，对于消息生产服务器100所生成的目标时间段内的业务消息集，按照两种不同类型的消息队列在目标时间段内各自对应的消息量比例，确定这两种不同类型的消息队列各自对应的业务消息子集。消息队列服务器200和消息队列服务器300从消息生产服务器100中接收到各自对应的业务消息子集并传输至业务子系统-2中对应的消费服务器节点。

消息消费服务器400和消息消费服务器500为业务子系统-2中的服务器，其中消息消费服务器400是与消息队列服务器200匹配的消费节点，消息消费服务器500是与消息队列服务器300匹配的消费节点，不同类型的消息队列对应的消费消息服务器的消息消费逻辑也会有所不同。

消息消费服务器400和消息消费服务器500对各自接收到业务消息子集中的任一子业务消息向锁竞争服务器600请求创建子业务消息对应的分布式锁，锁竞争服务器600可以为存储服务器，用于生成、记录分布式锁。在创建结果指示与子业务消息对应的分布式锁创建成功的情况下，对应的消息消费服务器获得对该子业务消息处理的权限，可以执行对子业务消息的处理。当消息消费服务器400和消息消费服务器500中各存在一条子业务消息对应于业务消息集中的同一条业务消息时，通过锁竞争使得仅对其中一条子业务消息执行处理，相当于不会对该条业务消息进行重复消费，保证了消息处理的准确可靠。

在一个可选的实施例中，上述服务器(消息生产服务器100、消息队列服务器200、消息队列服务器300、消息消费服务器400、消息消费服务器500、锁竞争服务器600)可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN(Content Delivery Network，内容分发网络)、以及大数据和人工智能平台等基础云计算服务的云服务器。

此外，需要说明的是，图1所示的仅仅是本公开提供的一种应用环境，在实际应用中，还可以包括其他应用环境，例如还可以有三类或三类以上的消息队列。

本说明书实施例中，上述消息生产服务器100、消息队列服务器200、消息队列服务器300、消息消费服务器400、消息消费服务器500、锁竞争服务器600之间可以通过有线或无线通信方式进行直接或间接地连接，本公开在此不做限制。

图2是根据一示例性实施例示出的一种消息处理方法的流程图。如图2所示，消息处理方法用于消息系统中，可以包括以下步骤：

在步骤S201中，获取目标时间段内的业务消息集，以及至少两种消息队列在目标时间段内各自对应的消息量比例。

在分布式业务系统中，常常利用消息队列进行业务子系统之间业务消息的异步传输，但是高并发的业务场景以及业务系统的不断扩展容易造成消息队列中消息传输的阻塞或延迟，消息传输的效率低下。在本说明书实施例中，通过设置多种类型的消息队列协同工作以对消息进行接收和传输，避免了单个类型的消息队列阻塞则传输服务不可用的问题，从而可以提高整个消息传输机制的可用性和消息吞吐量，缓解了高并发业务场景或分布式业务系统中的消息传输压力，有效提高消息传输的效率。

在本说明书实施例中，目标时间段对应一个预设的单位时间区间，将目标时间段内所生产的至少一条业务消息组成业务消息集，并以业务消息集为对象将其中所包含的全量的业务消息进行不同比例的划分和分配。

在本说明书实施例中，对于多种类型的消息队列，各消息队列对应有消息量比例，消息量比例表征消息队列所接收到的业务消息在业务消息集中所占的比例。不同的消息队列对应的消息量比例可以相同也可以不相同，为了不丢失任一条业务消息，各消息队列对应的消息量比例之和应不低于1。各消息队列对应的消息量比例之和大于1的情况表示存在同一条业务消息被分别发送至多个消息队列中。

可选的，可以根据各消息队列对应的单节点吞吐量和服务器节点个数，为不同的消息队列配置对应的消息量比例，消息量比例最高可以为100％，也即可以存在一个消息队列可以接收到业务消息集中全量的业务消息，消息量比例最低可以为0，也即可以存在一个消息队列可以暂时关闭。

在本说明书实施例中，各消息队列对应的消息量比例还与所处的时间段有关。在不同的时间段内，同一消息队列对应的消息量比例可以不同。示例性的，可以根据消息队列中排队等待的消息的数量、等待时长、业务类型、消息队列的类型等对消息队列在下一时间段内的消息量比例进行适应性地自动调整，从而可以避免出现消息队列的阻塞，提高了每个消息队列的可用性和消息传输效率，更好地实现多种消息队列的协同合作。

在步骤S203中，根据各自对应的消息量比例，从业务消息集中确定至少两种消息队列各自对应的业务消息子集。

在本说明书实施例中，按照消息队列在目标时间段内对应的消息量比例对业务消息集进行划分，确定与消息队列对应的业务消息子集，业务消息子集包括至少一条子业务消息，子业务消息对应于业务消息集中的一条业务消息。在从业务消息集中确定至少两种消息队列各自对应的业务消息子集时，多个业务消息子集的并集为全量的业务消息集，也即不会丢失业务消息集中的任一条业务消息。不同的消息队列各自对应的业务消息子集之间可以包含相同的子业务消息，也即多个业务消息子集之间可以存在重合，例如第一消息队列对应的第一业务消息子集中的第一子业务消息与第二消息队列对应的第二业务消息子集中的第二子业务消息对应于业务消息集中的同一条业务消息，则相当于同一条业务消息被分别发送至第一消息队列和第二消息队列，作为了对应的第一子业务消息与第二子业务消息。

在一种可行的实施方式中，以N个消息队列为例，选取一消息队列，该消息队列对应的消息量比例为100％，也即会接收全量的业务消息集，其他N-1个消息队列各自的消息量比例均为

且其他N-1个消息队列所对应接收到的业务消息子集之间没有重合的部分，从而可以保证业务消息的不丢失。

在另一种可行的实施方式中，同样以N个消息队列为例，每个消息队列对应的消息量比例均为

各消息队列所对应接收到的业务消息子集之间没有重合的部分。

在步骤S205中，对目标消息队列中的目标消息进行分布式锁创建处理，得到创建结果；目标消息队列为任一消息队列，目标消息为目标消息队列对应的业务消息子集中的任一子业务消息。

在本说明书实施例中，目标消息队列为至少两种消息队列中的任一消息队列，目标消息为目标消息队列对应的业务消息子集中的任一子业务消息，对目标消息进行分布式锁创建处理，得到创建结果，创建结果可以指示与目标消息对应的分布式锁创建成功或失败。

在分布式业务场景中消息的处理需要满足数据一致性的要求，在本说明书实施例中，考虑到多个消息队列对应的业务消息子集可能存在重合的部分，也即可能会出现多个业务消息子集中各自包含的一条子业务消息都对应于业务消息集中的同一条业务消息的情况，此时仅能对其中一条子业务消息执行处理或称进行消费，如果对与同一条业务消息对应的多个子业务消息都进行处理，相当于对该条业务消息进行了重复消费，则处理结果产生错误，不能满足数据一致性的要求。

在本说明书实施例中，利用分布式锁的创建结果，判断是否需要对目标消息进行处理。

在本说明书的一个实施例中，步骤S205可以包括以下实施步骤：

在步骤S2051中，确定目标消息的目标标识。

目标标识可以是目标消息不同维度的属性信息的组合。以支付业务中的目标消息为例，目标标识可以是支付账号、订单号、支付操作类型、支付状态等属性信息的组合。

在存在目标关联消息的情况下，目标关联消息的目标标识与目标消息的目标标识是相同的，目标关联消息与目标消息是业务消息集中的一条业务消息被分别发送至不同的消息队列后的结果。在不存在目标关联消息的情况下，目标消息与目标标识是一一对应的关系。

在步骤S2053中，基于目标标识，创建与目标消息对应的分布式锁，得到创建结果，创建结果指示与目标消息对应的分布式锁创建成功或失败。

在存在上述目标关联消息的情况下，目标关联消息与目标消息会形成锁竞争，若在先创建与目标消息对应的分布式锁，则会创建成功，若在后创建与目标消息对应的分布式锁(也即在先创建了与目标关联消息对应的分布式锁)，则与目标消息对应的分布式锁会创建失败。在不存在目标关联消息的情况下，与目标消息对应的分布式锁会创建成功。

在一种可行的实施方式中，可以基于数据库、缓存(如Redis(Remote DictionaryServer，远程字典服务)等)、文件系统(如Zookeeper(一个分布式的开放源码的分布式应用程序协调服务)等)等实现分布式锁。基于数据库的实现方式之一可以包括：在数据库中创建一个表，表中包含目标标识的字段，并为目标标识的字段创建唯一索引，在执行对目标消息的处理前，向表中目标标识的字段对应的行插入数据，成功插入则表明创建成功并获取到分布式锁，处理完成后删除对应的行数据，相当于释放对应的分布式锁。基于Redis的实现方式之一可以包括：使用命令SETNX(key，value)，其中SETNX的含义是SET ifNotExists，其中value对应目标标识，若不存在键值为目标标识的键key，则设置一个键值为value的键key，并返回1，此时表明分布式锁创建成功，若存在键值为目标标识的键key，则返回0，此时表明分布式锁创建失败；使用命令SETNX还可以设置一个超时时间，超过该时间则自动释放锁。基于Zookeeper的实现方式之一可以包括：创建一个目录，目标消息在目录下创建临时顺序节点，并获取目录下所有的子节点，如果不存在比临时顺序节点小的兄弟节点，则说明当前目标消息的顺序号最小，分布式锁创建成功，目标消息处理完后删除对应的临时顺序节点。

在上述实施例中，基于目标消息的目标标识尝试创建分布式锁，从而可以利用分布式锁的创建结果，判断是否需要对目标消息进行处理。

在步骤S207中，在创建结果指示创建成功的情况下，执行对目标消息的处理。

在本说明书实施例中，目标消息可能对应有目标关联消息，目标关联消息与目标消息是业务消息集中的一条业务消息被分别发送至不同的消息队列后的结果，也即可以认为目标关联消息与目标消息是不同消息队列对应的业务消息子集中相同的子业务消息。在存在目标关联消息的情况下，目标关联消息与目标消息会形成锁竞争，若在先创建与目标消息对应的分布式锁，则会创建成功，若在后创建与目标消息对应的分布式锁(也即在先创建了与目标关联消息对应的分布式锁)，则与目标消息对应的分布式锁会创建失败。在不存在目标关联消息的情况下，与目标消息对应的分布式锁会创建成功。

在本说明书实施例中，在创建结果指示创建成功的情况下，也即与目标消息队列对应的目标消费实例获取到了处理目标消息的权限。在一个可行的实施方式中，可以在创建结果指示创建成功的情况下，与目标消息队列对应的目标消费实例根据目标消息，更新业务数据。其中，目标消费实例与目标消息队列对应，目标消费实例执行与目标消息队列匹配的消息消费逻辑，在本说明书实施例中，消息的消费等同于消息的处理。目标消费实例所属的业务子系统负责业务数据的更新。

在本说明书实施例中，在创建结果指示创建失败(也即在先创建了与目标关联消息对应的分布式锁)的情况下，放弃对所述目标消息的处理。可以理解的是，目标关联队列中的目标关联消息对应的分布式锁已经创建成功，则与目标关联队列对应的目标关联消费实例获得了处理目标关联消息的权限。已对目标关联消息执行处理，则无需再对目标消息进行处理，可以实现对目标消息和目标关联消息所对应的相同的业务消息不进行重复消费，保证数据处理的准确性。

在本说明书的一个实施例中，在目标消息的处理状态为成功、失败或超时的情况下，释放分布式锁。以基于Redis实现分布式锁为例，在目标消息的处理状态为成功的情况下，删除以目标标识为键值的键，释放对应的分布式锁。在目标消息的处理状态为失败的情况下，释放对应的分布式锁以便可以尝试创建目标关联消息对应的分布式锁，或者是对目标消息的处理进行重试。当基于Redis实现的分布式锁还设置有超时时间时，当超过该时间自动释放分布式锁，以便可以尝试创建目标关联消息对应的分布式锁，或者是对目标消息的处理进行重试，提高消息处理的效率。

由上述实施例可知，本说明书实施例所提供的消息处理方法中将目标时间段内的业务消息集，按照至少两种消息队列在目标时间段内各自对应的消息量比例，分配给各消息队列，每种消息队列接收到各自对应的业务消息子集并进行传输；对于目标消息队列中的目标消息进行分布式锁创建处理，得到创建结果，其中目标消息队列是至少两种消息队列中的任一消息队列，目标消息是目标消息队列对应的业务消息子集中的任一子业务消息；在创建结果指示分布式锁创建成功的情况下，执行对目标消息的处理。本公开实施例所提供的技术方案通过多种消息队列协同工作以对消息进行接收和传输，缓解了高并发业务场景或分布式业务系统中的消息传输压力，提高了消息传输机制的可用性和消息吞吐量，从而可以提高消息传输的效率；并且可以通过各消息队列在不同时间段内对应的消息量比例调整各消息队列所要接收并传输的消息量，更好地实现多种消息队列的协同合作，避免出现消息队列的阻塞，提高了每个消息队列的可用性；通过消息队列在不同时间段内各自对应的消息量比例进行业务消息的分配，各消息队列对应的业务消息子集之和覆盖全部的业务消息集，可以实现业务消息的不丢失，以及对各消息队列对应的业务消息子集中的任一子业务消息创建分布式锁，在创建成功的情况才执行处理，可以保证业务消息集中的业务消息不会被重复处理，保证消息处理的可靠和准确。

图3是根据一示例性实施例示出的一种应用于消息队列迁移过程中不同时间段内消息队列的消息量比例示意图。在消息队列的迁移过程中，为了不影响在线业务，不会直接关停迁移前的消息队列后再启用迁移后的消息队列，而是会让迁移前的消息队列和迁移后的消息队列同时工作一段时间作为过渡，此时过渡阶段的消息处理方法也是本说明书实施例所提供的消息处理方法在消息队列迁移应用中的具体实施。以至少两种消息队列包括第一消息队列和第二消息队列为例，为了实现从第一消息队列切换到第二消息队列，步骤S203可以实施为：

根据各自对应的消息量比例，从业务消息集中确定第一业务消息子集和第二业务消息子集；

在目标时间段处于消息队列迁移的第一阶段中的情况下，第一业务消息子集对应所述业务消息集中全部的业务消息，第二业务消息子集对应业务消息集中局部的业务消息；

在目标时间段处于消息队列迁移的第二阶段中的情况下，第一业务消息子集对应所述业务消息集中局部的业务消息，第二业务消息子集对应业务消息集中全部的业务消息；

其中，第一阶段在第二阶段之前。

如图3所示，从第一消息队列切换到第二消息队列的过渡阶段为T1至T10的时间区间，其中T1至T4的时间区间为第一阶段，T6至T10的时间区间为第二阶段，T5可以为保持阶段。为了实现从第一消息队列切换到第二消息队列，发送至第一消息队列中的第一子业务消息的数量需要逐渐减少至零，发送至第二消息队列中的第二子业务消息的数量需要逐渐增多为全量。在目标时间段处于消息队列迁移的第一阶段中的情况下，第一消息队列对应的消息量比例均为100％，第一消息队列对应的第一业务消息子集所包括的第一子业务消息与业务消息集中的业务消息一一对应，也即第一业务消息子集等同于全量的业务消息集；如目标时间段为T4，第二消息队列对应的消息量比例为80％，也即第二业务消息子集所包括的第二子业务消息与业务消息集中80％的业务消息对应，但是第一阶段，第二消息队列对应的消息量比例会逐渐增加至100％。

在目标时间段处于消息队列迁移的第二阶段中的情况下，第二消息队列对应的消息量比例均为100％，第二消息队列对应的第二业务消息子集所包括的第二子业务消息与业务消息集中的业务消息一一对应，也即第二业务消息子集等同于全量的业务消息集；如目标时间段为T9，第一消息队列对应的消息量比例为20％，也即第一业务消息子集所包括的第一子业务消息与业务消息集中20％的业务消息对应，但是第二阶段，第一消息队列对应的消息量比例会逐渐减少为0。

在上述实施例中，通过对迁移前后的两个消息队列对应的消息量比例的控制，实现业务消息的完整，从而避免对用户体验的负面影响。

可选的，第一消息队列和第二消息队列各自对应的消息量比例均为100％的时间段(如图3中的T5)可以为一个或多个预设的单位时间时长，在该时间段内，对第二消息队列消息传输的效果进行验证，验证通过后再进入第二阶段。

可行地，当第一业务消息子集的消息量减少至零时，断开与第一消息队列的通信连接。进一步地，在第一业务消息子集的消息量减少至零且第一消息队列中没有等待传输的第一子业务消息后，断开与第一消息队列的通信连接，完成消息队列的切换。

在另一种可行的实施方式中，从第一消息队列切换到第二消息队列的过程中消息量比例还可以设置为：在目标时间段处于消息队列迁移的第一阶段中的情况下，第一消息队列和第二消息队列各自对应的消息量比例均为100％，在对第二消息队列消息传输的效果验证通过后进入第二阶段，第二消息队列对应的消息量比例仍为100％，第一消息队列对应的消息量比例逐渐减少为零，直至断开通信连接，也可以实现业务消息的完整。

图4是根据一示例性实施例示出的一种具体业务中的消息处理方法的流程图。如图4所示，在创建结果指示创建成功的情况下，与目标消息队列对应的目标消费实例根据目标消息，更新业务数据，其中业务数据可以包括业务日志数据，具体地对业务数据的更新可以包括：

在步骤S401中，确定目标消息的目标日志索引标识。

目标日志索引标识可以是目标消息不同维度的属性信息的组合。以支付业务中的目标消息为例，目标日志索引标识可以是支付账号、订单号、支付操作类型、支付状态等属性信息的组合。

在步骤S403中，在业务日志数据中不存在目标日志索引标识的情况下，将目标消息添加至业务日志数据中，并更新业务日志数据。

对于业务日志数据，每一条目标消息的处理结果是相互独立的。通过检索是否存在可以唯一标识目标消息的目标日志索引标识，避免对同一业务消息的重复记录，保证数据存储的准确性。

如图4所示，业务数据还可以包括业务统计数据，具体地对业务数据的更新还可以包括：

在步骤S402中，在目标消费实例具有重试机制的情况下，确定与目标消息对应的目标统计标识。

日志统计标识也可以是目标消息不同维度的属性信息的组合，以支付业务中的目标消息为例，日志统计标识也可以是支付账号、订单号、支付操作类型、支付状态、周期等属性信息的组合。

在步骤S404中，在目标统计标识指示目标消息未被统计过的情况下，根据目标消息更新业务统计数据。

在一种可行的实施方式中，在目标消费实例具有重试机制的情况下为了避免重复统计，可以基于Redis的SETNX命令尝试生成与目标统计标识对应的键值对，若生成成功，则说明目标消息未被统计过，若生成失败，则说明目标消息已被统计过，可以直接跳过对该条目标消息的统计。

通过检索是否存在可以指示目标消息是否被统计过的目标统计标识，可以避免重复统计，实现业务统计数据的准确性。

对于不具备重试机制的目标消费实例，则可以直接生成异常事件并退出对目标统计数据的数据。

对于上述的业务日志数据和业务统计数据，均可以采取数据库分片存储机制，减小每个数据库服务器节点的数据访问压力，从而提高整个数据库系统的性能。

图4是针对具体业务类型提供的消息处理的示例，在实际应用中，可以根据所采用的消息队列对应的消费逻辑、业务类型等适应性地设计处理规则，本说明书实施例对此不作限定。

图5是根据一示例性实施例示出的一种应用于消息队列迁移过程中消息处理方法的完整流程示意图。图5展示了在以分布式业务系统中的多种操作类型所产生的资源转移消息作为业务消息，以Kafka和RocketMQ作为迁移前后的消息队列的情况下消息队列迁移过程中的消息处理流程，其中多种操作类型包括分配、提取、兑换、回收等操作，可以通过远程过程调用(Remote Procedure Call，RPC)实现不同的操作并得到待处理的资源转移消息。

随着业务量级的持续增长，分布式业务系统对消息队列的并发处理能力、可用性和数据传输处理的可靠准确的要求也会越来越高，由于Kafka本身不具备重试机制，不符合支付高并发场景下对性能以及数据最终一致性的要求，因此需要将分布式业务系统中的消息队列从Kafka切换到具有重试机制的RocketMQ。在切换过程中，为了不影响在线业务的正常使用，不会直接关停Kafka后再启用RocketMQ，而是会让Kafka和RocketMQ同时工作一段时间作为过渡。在同时工作的时间内，Kafka在单位时间内所接收到的资源转移消息初始是全量的，RocketMQ在单位时间内所接收到的资源转移消息的数量会逐步增加，当随着RocketMQ在单位时间内所接收到的资源转移消息的数量变为全量并验证消息传输效果后，Kafka在单位时间内所接收到的资源转移消息会逐渐较少为零。Kafka和RocketMQ在单位时间内对应的消息量比例可以参考图3所提供的实施例内容，可以保证迁移过程中不丢失任一条资源转移消息，此处不再赘述。

对于目标时间段内的资源转移消息集，根据Kafka和RocketMQ各自对应的消息量比例，从资源转移消息集中确定Kafka对应的第一资源转移消息子集和RocketMQ对应的第二资源转移消息子集，Kafka对应的Kafka消费实例负责对第一资源转移消息子集进行处理，RocketMQ对应的RocketMQ消费实例负责对第二资源转移消息子集进行处理。

在迁移过程中，会存在第一资源转移消息子集中的第一子资源转移消息和第二资源转移消息子集中的第二子资源转移消息都对应于同一条资源转移消息，也即是第一资源转移消息子集和第二资源转移消息子集重合的部分。故对于目标消息，其可能存在目标关联消息，目标消息和目标关联消息中的一个来自于Kafka消费实例，另一个可以来自于RocketMQ消费实例，二者对应于资源转移消息集中的同一条资源转移消息。为了避免对资源转移消息的重复消费以保证数据的准确性，在Kafka消费实例和RocketMQ消费实例的消费入口位置通过Redis实现了一个锁竞争机制。以目标消息来自Kafka消费实例、目标关联消息来自于RocketMQ消费实例为例，目标关联消息与目标消息会形成锁竞争，二者对应的标识(也即SETNX命令中的Value)相同，只能创建一个与该标识对应的锁，也即目标关联消息和目标消息只能有一个会被处理。若在先创建与目标消息对应的分布式锁，则由Kafka消费实例执行对目标消息的处理，而RocketMQ消费实例会丢弃掉目标关联消息，放弃对其的处理；若在先创建与目标关联消息对应的分布式锁，则由RocketMQ消费实例执行对目标关联消息的处理，而Kafka消费实例会丢弃掉目标消息，放弃对其的处理。

对于资源转移消息的处理包括资源日志数据的更新和资源统计数据的更新。对于资源日志数据和资源统计数据，通过资源日志数据集群和资源统计数据集群分别实现对资源日志数据和资源统计数据的分片存储，图5中所展示的资源日志数据Kshard和资源统计数据Kshard为其中的一个分片。同样以目标消息来自Kafka消费实例、目标关联消息来自于RocketMQ消费实例为例，在Kafka消费实例竞争到锁并对目标消息执行处理时，先根据目标消息对资源日志数据进行更新，再对资源统计数据进行更新，由于Kafka消费实例不具有重试机制，在消费失败的情况下会直接生成异常事件并报警退出，此时由于消费税失败需要通过删除标识释放对应的锁；在RocketMQ消费实例竞争到锁并对目标关联消息执行处理时，也可以先更新资源日志消息，后对资源统计数据进行更新，在消费失败的情况下，需要通过删除标识释放对应的锁，由于RocketMQ消费实例具有重试机制，在重试环节可以通过资源日志数据Kshard中可以唯一表征目标关联消息的日志索引标识是否存在来判断是否记录过该目标关联消息，从而保证资源日志数据的记录准确。RocketMQ消费实例在根据目标关联消息对资源统计数据进行更新时，通过增加的Redis打标逻辑来保证同一份目标关联消息只会被统计一次，具体地，可以通过SETNX命令设置与统计标识对应的键值对，若设置成功则表示还没统计过，则直接根据目标关联消息对资源统计数据进行更新，若设置失败则表示已经统计过，直接跳过对资源统计数据的更新。

通过上述实施例所提供的应用于消息队列迁移过程中的消息处理方法，可以在不影响在线业务和用户体验的情况下实现消息队列的迁移，并且可以保证业务消息的完整，其次消息队列的迁移风险低，由于在两种消息队列消费入口位置增加了Reids锁竞争机制，所以不会出现重复消费，保证了数据的准确。这种消息队列的迁移方式和消息处理方式适合高并发的业务场景，具有可复制性。

图6是根据一示例性实施例示出的一种消息处理装置框图。参照图6，该装置600包括：

获取模块610，被配置为执行获取目标时间段内的业务消息集，以及至少两种消息队列在所述目标时间段内各自对应的消息量比例；

子集确定模块620，被配置为执行根据所述各自对应的消息量比例，从所述业务消息集中确定所述至少两种消息队列各自对应的业务消息子集；

锁模块630，被配置为执行对目标消息队列中的目标消息进行分布式锁创建处理，得到创建结果；所述目标消息队列为任一消息队列，所述目标消息为所述目标消息队列对应的业务消息子集中的任一子业务消息；

消息处理模块640，被配置为执行在所述创建结果指示创建成功的情况下，执行对所述目标消息的处理。

可选的，所述至少两种消息队列包括第一消息队列和第二消息队列，所述子集确定模块620包括：

子集确定单元，被配置为执行根据所述各自对应的消息量比例，从所述业务消息集中确定第一业务消息子集和第二业务消息子集；

在所述目标时间段处于消息队列迁移的第一阶段中的情况下，所述第一业务消息子集对应所述业务消息集中全部的业务消息，所述第二业务消息子集对应所述业务消息集中局部的业务消息；

在所述目标时间段处于消息队列迁移的第二阶段中的情况下，所述第一业务消息子集对应所述业务消息集中局部的业务消息，所述第二业务消息子集对应所述业务消息集中全部的业务消息；

所述第一阶段在所述第二阶段之前。

可选的，所述子集确定单元还包括：

切换子单元，被配置为执行当所述第一业务消息子集的消息量减少至零时，断开与所述第一消息队列的通信连接。

可选的，所述锁模块630包括：

标识确定单元，被配置为执行确定所述目标消息的目标标识；

锁创建单元，被配置为执行基于所述目标标识，创建与所述目标消息对应的分布式锁，得到创建结果，所述创建结果指示与所述目标消息对应的分布式锁创建成功或失败。

可选的，所述装置600还包括：

丢弃模块，被配置为执行在所述创建结果指示创建失败的情况下，放弃对所述目标消息的处理。

可选的，所述消息处理模块640包括：

业务更新单元，被配置为执行在所述创建结果指示创建成功的情况下，与所述目标消息队列对应的目标消费实例根据所述目标消息，更新业务数据。

可选的，所述业务更新单元包括：

日志标识确定子单元，被配置为执行确定所述目标消息的目标日志索引标识；

业务日志数据更新子单元，被配置为执行在所述业务日志数据中不存在所述目标日志索引标识的情况下，将所述目标消息添加至所述业务日志数据中，并更新所述业务日志数据。

可选的，所述业务更新单元还包括：

统计标识确定子单元，被配置为执行在所述目标消费实例具有重试机制的情况下，确定与所述目标消息对应的目标统计标识；

业务统计数据更新子单元，被配置为执行在所述目标统计标识指示所述目标消息未被统计过的情况下，根据所述目标消息更新所述业务统计数据。

可选的，所述装置600还包括：

锁释放单元，被配置为执行在所述目标消息的处理状态为成功、失败或超时的情况下，释放所述分布式锁。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

在示例性实施例中，还提供了一种电子设备，包括：处理器；用于存储该处理器可执行指令的存储器；其中，该处理器被配置为执行该指令，以实现如本公开实施例中的消息处理方法。

图7是根据一示例性实施例示出的一种用于实现消息处理方法的电子设备的框图，该电子设备可以是服务器，其内部结构图可以如图7所示。该电子设备包括通过系统总线连接的处理器、存储器和网络接口。其中，该电子设备的处理器用于提供计算和控制能力。该电子设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该电子设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现消息处理方法。

本领域技术人员可以理解，图7中示出的结构，仅仅是与本公开方案相关的部分结构的框图，并不构成对本公开方案所应用于其上的电子设备的限定，具体的电子设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在示例性实施例中，还提供了一种包括指令的计算机可读存储介质，当计算机可读存储介质中的指令由电子设备的处理器执行时，使得所述电子设备能够执行本公开实施例中的消息处理方法。

在示例性实施例中，还提供一种计算机程序产品，包括计算机指令，所述计算机指令被处理器执行时实现本公开实施例中的消息处理方法。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，该计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims (12)

1.一种消息处理方法，其特征在于，所述方法包括：

获取目标时间段内的业务消息集，以及至少两种消息队列在所述目标时间段内各自对应的消息量比例；

根据所述各自对应的消息量比例，从所述业务消息集中确定所述至少两种消息队列各自对应的业务消息子集；

对目标消息队列中的目标消息进行分布式锁创建处理，得到创建结果；所述目标消息队列为任一消息队列，所述目标消息为所述目标消息队列对应的业务消息子集中的任一子业务消息；

在所述创建结果指示创建成功的情况下，执行对所述目标消息的处理。

2.根据权利要求1所述的方法，其特征在于，所述至少两种消息队列包括第一消息队列和第二消息队列，所述根据所述各自对应的消息量比例，从所述业务消息集中确定所述至少两种消息队列各自对应的业务消息子集，包括：

根据所述各自对应的消息量比例，从所述业务消息集中确定第一业务消息子集和第二业务消息子集；

在所述目标时间段处于消息队列迁移的第一阶段中的情况下，所述第一业务消息子集对应所述业务消息集中全部的业务消息，所述第二业务消息子集对应所述业务消息集中局部的业务消息；

在所述目标时间段处于消息队列迁移的第二阶段中的情况下，所述第一业务消息子集对应所述业务消息集中局部的业务消息，所述第二业务消息子集对应所述业务消息集中全部的业务消息；

所述第一阶段在所述第二阶段之前。

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

当所述第一业务消息子集的消息量减少至零时，断开与所述第一消息队列的通信连接。

4.根据权利要求1所述的方法，其特征在于，所述对目标消息队列中的目标消息进行分布式锁创建处理，得到创建结果，包括：

确定所述目标消息的目标标识；

基于所述目标标识，创建与所述目标消息对应的分布式锁，得到创建结果，所述创建结果指示与所述目标消息对应的分布式锁创建成功或失败。

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

在所述创建结果指示创建失败的情况下，放弃对所述目标消息的处理。

6.根据权利要求1所述的方法，其特征在于，所述在所述创建结果指示创建成功的情况下，执行对所述目标消息的处理，包括：

在所述创建结果指示创建成功的情况下，与所述目标消息队列对应的目标消费实例根据所述目标消息，更新业务数据。

7.根据权利要求6所述的方法，其特征在于，所述业务数据包括业务日志数据和所述根据所述目标消息，更新业务数据，包括：

确定所述目标消息的目标日志索引标识；

在所述业务日志数据中不存在所述目标日志索引标识的情况下，将所述目标消息添加至所述业务日志数据中，并更新所述业务日志数据。

8.根据权利要求6所述的方法，其特征在于，所述业务数据包括业务统计数据，所述根据所述目标消息，更新业务数据，还包括：

在所述目标消费实例具有重试机制的情况下，确定与所述目标消息对应的目标统计标识；

在所述目标统计标识指示所述目标消息未被统计过的情况下，根据所述目标消息更新所述业务统计数据。

9.根据权利要求1所述的方法，其特征在于，在所述执行对所述目标消息的处理之后，所述方法还包括：

在所述目标消息的处理状态为成功、失败或超时的情况下，释放所述分布式锁。

10.一种消息处理装置，其特征在于，所述装置包括：

获取模块，被配置为执行获取目标时间段内的业务消息集，以及至少两种消息队列在所述目标时间段内各自对应的消息量比例；

子集确定模块，被配置为执行根据所述各自对应的消息量比例，从所述业务消息集中确定所述至少两种消息队列各自对应的业务消息子集；

锁模块，被配置为执行对目标消息队列中的目标消息进行分布式锁创建处理，得到创建结果；所述目标消息队列为任一消息队列，所述目标消息为所述目标消息队列对应的业务消息子集中的任一子业务消息；

消息处理模块，被配置为执行在所述创建结果指示创建成功的情况下，执行对所述目标消息的处理。

11.一种电子设备，其特征在于，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现如权利要求1至9中任一项所述的消息处理方法。

12.一种计算机可读存储介质，其特征在于，当所述计算机可读存储介质中的指令由电子设备的处理器执行时，使得所述电子设备能够执行如权利要求1至9中任一项所述的消息处理方法。

Images