CN111008087A - 一种消息处理方法及装置 - Google Patents

Abstract

本发明实施例提出的一种消息处理方法及装置，获取消息处理请求，根据消息处理请求中携带的队列名称和队列类型确定对应的目标队列，并根据消息处理请求的类型和队列类型从预设处理策略中确定目标处理策略，进而根据消息处理请求、目标队列和处理策略进行消息处理。本方案可以根据实际的消息处理请求自动确定对应的目标队列和处理策略，无需书写代码，更加省时和方便。

Description

一种消息处理方法及装置

技术领域

本发明实施例涉及数据处理技术领域，具体涉及一种消息处理方法及装置。

背景技术

现有对消息的处理通常包括生产消息和消费消息这两种类型，在生产消息过程中，通常需要采用处理策略将消息存储至队列中，在消费消息的过程中，通常需要采用处理策略从队列中提取待消费消息。

针对同一类型的队列，在生产消息或消费消息的过程中，采用的处理策略通常是一样的，例如对于类型为redis(remote dictionary server，远程字典服务器)的队列在生产消息过程中通常采用的处理策略都是rpush方法(将消息存储在队列的队尾)，在消费消息过程中通常采用的处理策略都是blpop方法(提取队列中位于队首的消息)。

现有的在进行消息处理时，通常采用书写代码的方式来调用处理策略，而在调用同一处理策略时其书写的代码通常是雷同的，这就导致利用现有方式进行消息处理时，通常需要书写雷同的代码来实现处理策略的调用，比较耗时。

上述对问题的发现过程的描述，仅用于辅助理解本发明的技术方案，并不代表承认上述内容是现有技术。

发明内容

为了解决上述技术问题或者至少部分地解决上述技术问题，本发明实施例提供了一种消息处理方法及装置。

有鉴于此，第一方面，本发明实施例提供一种消息处理方法，包括：

接收消息处理请求，所述消息处理请求包含消息处理请求的类型、队列名称和队列类型；

根据所述队列名称和队列类型确定与所述消息处理请求对应的目标队列；

根据所述消息处理请求的类型和队列类型，从预设的处理策略中确定与所述消息处理请求对应的目标处理策略；

根据所述消息处理请求、所述目标队列和所述目标处理策略进行消息处理。

在一种可能的实现方式中，所述消息处理请求包含还取模字段；

根据所述队列名称和队列类型确定与所述消息处理请求对应的目标队列，包括：

采用预设的转换算法将所述取模字段转换为数字；

获取预设的队列配置信息中包含的所述队列名称对应的队列数量；

利用所述队列数量对所述数字进行求余计算，得到所述数字的余数；

利用所述队列名称和所述余数组成目标队列名称；

根据所述目标队列名称和所述队列类型确定目标队列。

在一种可能的实现方式中，根据所述消息处理请求的类型和队列类型，从预设的处理策略中确定与所述消息处理请求对应的目标处理策略，包括：

根据预设的处理策略与消息处理请求的类型和队列类型之间的对应关系，从预设的处理策略中确定与所述消息处理请求中包含的消息处理请求的类型和队列类型对应的处理策略，作为与所述消息处理请求对应的目标处理策略。

在一种可能的实现方式中，若所述消息处理请求的类型为生产消息请求，所述消息处理请求还包含具体的消息；

根据所述消息处理请求、所述目标队列和所述目标处理策略进行消息处理，包括：

执行所述目标处理策略，以将所述消息处理请求中包含的具体的消息存储至所述目标队列中。

在一种可能的实现方式中，若所述消息处理请求的类型为消费消息请求，所述消息处理请求还包含队列数量、业务方标识以及业务方对应的处理方法，所述业务方为发送所述消费消息请求的应用程序；

根据所述消息处理请求、所述目标队列和所述目标处理策略进行消息处理，包括：

启动第一数量个线程，所述第一数量与所述消息处理请求中包含的队列数量相同；

每个所述线程分别执行所述目标处理策略，以从所述目标队列中获取待消费消息；

将所述待消费消息发送至与所述业务方标识对应的业务方，以使所述业务方执行所述业务方对应的处理方法对所述待消费消息进行消费。

在一种可能的实现方式中，所述方法还包括：

获取所述业务方对所述待消费消息的消费结果；

若所述消费结果为消费失败，则将所述待消费消息再次发送至所述业务方，以使所述业务方采用所述业务方对应的处理方法对所述待消费消息进行消费，直至消费成功或预设时长内该业务方对该待消费消息的消费次数达到预设的阈值。

第二方面，本发明实施例还提供了一种消息处理装置，包括：

接收模块，用于接收消息处理请求，所述消息处理请求包含消息处理请求的类型、队列名称和队列类型；

目标队列确定模块，用于根据所述队列名称和队列类型确定与所述消息处理请求对应的目标队列；

目标处理策略确定模块，用于根据所述消息处理请求的类型和队列类型，从预设的处理策略中确定与所述消息处理请求对应的目标处理策略；

处理模块，用于根据所述消息处理请求、所述目标队列和所述目标处理策略进行消息处理。

在一种可能的实现方式中，所述消息处理请求包含还取模字段；

所述目标队列确定模块，具体用于：

采用预设的转换算法将所述取模字段转换为数字；

获取预设的队列配置信息中包含的所述队列名称对应的队列数量；

利用所述队列数量对所述数字进行求余计算，得到所述数字的余数；

利用所述队列名称和所述余数组成目标队列名称；

根据所述目标队列名称和所述队列类型确定目标队列。

在一种可能的实现方式中，所述目标处理策略确定模块，具体用于：

根据预设的处理策略与消息处理请求的类型和队列类型之间的对应关系，从预设的处理策略中确定与所述消息处理请求中包含的消息处理请求的类型和队列类型对应的处理策略，作为与所述消息处理请求对应的目标处理策略。

在一种可能的实现方式中，若所述消息处理请求的类型为生产消息请求，所述消息处理请求还包含具体的消息；

所述处理模块，具体用于：

执行所述目标处理策略，以将所述消息处理请求中包含的具体的消息存储至所述目标队列中。

在一种可能的实现方式中，若所述消息处理请求的类型为消费消息请求，所述消息处理请求还包含队列数量、业务方标识以及业务方对应的处理方法，所述业务方为发送所述消费消息请求的应用程序；

所述处理模块，具体用于：

启动第一数量个线程，所述第一数量与所述消息处理请求中包含的队列数量相同；

每个所述线程分别执行所述目标处理策略，以从所述目标队列中获取待消费消息；

将所述待消费消息发送至与所述业务方标识对应的业务方，以使所述业务方执行所述业务方对应的处理方法对所述待消费消息进行消费。

在一种可能的实现方式中，所述装置还包括：

重试模块，具体用于获取所述业务方对所述待消费消息的消费结果；若所述消费结果为消费失败，则将所述待消费消息再次发送至所述业务方，以使所述业务方采用所述业务方对应的处理方法对所述待消费消息进行消费，直至消费成功或预设时长内该业务方对该待消费消息的消费次数达到预设的阈值。第三方面，本发明实施例还提供了一种电子设备，包括：

处理器、存储器、通信接口和总线；

其中，所述处理器、存储器、通信接口通过所述总线完成相互间的通信；

所述通信接口用于外部设备之间的信息传输；

所述处理器用于调用所述存储器中的程序指令，以执行第一方面所述的消息处理方法的步骤。

第四方面，本发明实施例还提供了一种可读存储介质，所述可读存储介质存储计算机指令，所述计算机指令使所述计算机执行第一方面任一所述的消息处理方法的步骤。

相比现有技术，本发明实施例提出的一种消息处理方法，获取消息处理请求，根据消息处理请求中携带的队列名称和队列类型确定对应的目标队列，并根据消息处理请求的类型和队列类型从预设处理策略中确定目标处理策略，进而根据消息处理请求、目标队列和处理策略进行消息处理。本方案可以根据实际的消息处理请求自动确定对应的目标队列和处理策略，无需书写代码，更加省时和方便。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍。

图1为本发明实施例提供的一种消息处理方法的流程图；

图2为本发明实施例提供的一种确定目标队列的流程图；

图3为本发明实施例提供的一种消息的消费过程的流程图；

图4为本发明实施例提供的一种消息处理方法的示意图；

图5为本发明实施例提供的一种消息处理装置的框图；

图6为本发明实施例提供的一种电子设备的示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述。

图1为本发明实施例提供的一种消息处理方法的流程图，该方法基于jdk1.8和spring boot框架开发，在执行该方法前，在spring容器启动的时候通过@Post Construct注解(被@Post Construct修饰的方法会在服务器加载服务连接器Servlet的时候运行，并且只会被服务器执行一次)，初始化队列的配置得到预设的队列配置信息，其中队列为消息队列即用于存储消息的队列，并且将预设的队列的配置信息保存到hash Map中，其中配置信息可以包括队列名称、队列名称对应的缓存节点和各队列名称对应的队列数量等等，其中队列类型可以为redis(remote dictionary server，远程字典服务器)或rocketmq(一款分布式、队列模型的消息中间件)等。

如图1所示，该方法可以包括如下步骤：

S11.接收消息处理请求，所述消息处理请求包含消息处理请求的类型、队列名称和队列类型。

其中队列名称和队列类型为消息对应的名称和类型。

消息处理请求是由业务方发送的用于对消息进行处理的请求，其类型可以为生产消息请求也可以为消费消息请求，其中生产消息请求是用于请求进行消息生产处理，消费消息请求是用于请求进行消息消费处理。

为了确定消息处理请求是生产消息请求还是消费消息请求，在消息处理请求中包含有消息处理请求的类型(生产消息请求或消费消息请求)，其中类型可以用简单的标识表示，例如用1标识生产消息请求，0表示消费消息请求，等等，只要是能够用于对消息处理请求的类型进行区分的标识即可。

S12.根据所述队列名称和队列类型确定与所述消息处理请求对应的目标队列。

在进行消息处理时通常会用到队列，例如在生产消息过程中需要将消息存储至队列，在消费消息过程中需要从队列中提取待消费消息等等，所以在进行消息处理之前需要先确定消息处理请求对应的目标队列。

在一种可能的实现方式中，可以根据队列名称和队列类型创建目标队列。

在一种可能的实现方式中，还可以从预先建立的队列中，选取队列名称与消息处理请求中的队列名称一致，且队列类型与消息处理请求中的队列类型一致的队列作为目标队列。

S13.根据所述消息处理请求的类型和队列类型，从预设的处理策略中确定与所述消息处理请求对应的目标处理策略。

在本实施例中，该消息处理方法应用于服务器，在执行S13之前，预先将处理策略进行统一封装并存储在服务器的本地磁盘中或服务器可以访问的数据节点中，只需知道处理策略的名称等标识，即可直接调用对应的处理策略，无需书写代码，更加方便和省时省力。

在一种可能的实现方式中，预先建立处理策略与消息处理请求的类型和队列类型的对应关系表，通过查表的方式确定与消息处理请求的类型和消息处理请求的类型含有的队列类型对应的处理策略，并以该处理策略作为与消息处理请求对应的目标处理策略。

例如预先设定：

若所述消息处理请求为消息生成请求，且所述队列类型为远程字典服务Redis，则确定预设的rpush方法为与所述消息处理请求对应的目标处理策略，所述rpush方法为将消息存储在目标队列的队尾。

若所述消息处理请求为消息生产请求，且所述队列类型为分布式消息中间件rocketmq，则确定预设的asyncSend方法为与所述消息处理请求对应的目标处理策略，所述asyncSend方法为将消息一个一个的存储至目标队列中；

若所述消息处理请求为消息消费请求，且所述队列类型为远程字典服务Redis，则确定预设的blpop方法为与所述消息处理请求对应的目标处理策略，所述blpop方法为获取目标队列中队首的消息；

若所述消息处理请求为消息消费请求，且所述队列类型为分布式消息中间件rocketmq，则确定预设的push方法为与所述消息处理请求对应的目标处理策略，所述push方法为主动从目标队列中获取消息。

S14.根据所述消息处理请求、所述目标队列和所述目标处理策略进行消息处理。

在确定了目标队列后，即可采用目标处理策略根据消息处理请求中携带的内容进行消息处理。

在一种可能的实现方式中，若所述消息处理请求的类型为生产消息请求，则消息处理请求中会携带有生产出来的具体的消息，根据所述消息处理请求、所述目标队列和所述目标处理策略进行消息处理，包括：

执行所述目标处理策略，以将所述消息处理请求中包含的具体的消息存储至所述目标队列中。

在具体实施时，将消息存储至目标队列中通常是存储至目标队列对应的缓存节点中，而目标队列对应的缓存节点可以根据预设的队列配置来确定，目标队列对应的缓存节点即为消息处理请求中包含的队列名称所对应的缓存节点，所以根据消息处理请求中包含的队列名称从预设的队列配置信息中查找与该队列名称对应的缓存节点，找到的缓存节点即为目标队列对应的缓存节点。

在一种可能的实现方式中，若所述消息处理请求的类型为消费消息请求，根据所述消息处理请求、所述目标队列和所述目标处理策略进行消息处理，包括：

执行所述目标处理策略，获取所述目标队列中的消息作为待消费消息，根据所述消息处理请求将待消费消息发送至发送消息处理请求的业务方进行消费。

本实施例提出的一种消息处理方法，获取消息处理请求，根据消息处理请求中携带的队列名称和队列类型确定对应的目标队列，并根据消息处理请求的类型和队列类型从预设处理策略中确定目标处理策略，进而根据消息处理请求、目标队列和处理策略进行消息处理。本方案可以根据实际的消息处理请求自动确定对应的目标队列和处理策略，无需书写代码，更加省时和方便。

在一种可能的实现方式中，为了避免太多的消息处理请求被分配至同一个目标队列造成队列处理缓慢，消息处理请求中还包含有取模字段(例如用户ID，游戏房间ID等带有标识作用的字段)，在上述消息处理方法的基础上，S12可以根据取模字段和队列名称生成新的队列名称作为目标队列名称，然后根据目标队列名称和队列类型确定目标队列，具体的如图2所示，可以采用下述方式确定目标队列：

S121.采用预设的转换算法将所述取模字段转换为数字。

通常取模的字段为用户ID、游戏房间ID等带有字符的字段，所以为了进行计算，需要先将取模字段转换成数字。

其中转换算法可以为现有的能够将字符转换成数字的算法，例如CRC32算法。

S122.获取预设的队列配置信息中包含的所述队列名称对应的队列数量。

S123.利用所述队列数量对所述数字进行求余计算，得到所述数字的余数。

S124.利用所述队列名称和所述余数组成目标队列名称。

其中目标队列名称的格式可以根据需求设定，例如可以为：“队列名称：余数”，或，“队列名称，余数”等格式。

S125.根据所述目标队列名称和所述队列类型确定目标队列。

在一种可能的实现方式中，可以根据目标队列名称和队列类型创建目标队列。

在一种可能的实现方式中，还可以从预先建立的队列中，选取队列名称与目标队列名称一致，且队列类型与消息处理请求中的队列类型一致的队列作为目标队列。

本实施例提供的一种根据消息处理请求中的取模字段和队列名称组成新的队列名称作为目标队列名称，然后根据目标队列名称确定目标队列，通过这种方式，即使不同的消息处理请求中携带的队列名称相同，其对应的目标队列也可能为不同的队列，从而避免了太多消息处理请求被分配至同一目标队列。

在一种可能的实现方式中，还有一种方式解决目标队列中消息太多的问题，确定出目标队列后，检测目标队列中有消息积压，如果目标队列中有消息积压，则可以对目标队列进行扩容，通过扩容可以解决由于消息积压导致的后续消息无法处理的问题。

在一种可能的实现方式中，若消息处理请求的类型为消费消息请求，则该消息处理请求中除了消息处理请求的类型、队列名称和队列类型还可以包含队列数量、取模字段、业务方标识(用于标识发送该消息处理请求的业务方)以及业务方对应的处理方法等参数，其中业务方为发送所述消费消息请求的应用程序，业务方对应的处理方法用于对消息进行消费。如图3所示，在上述消息处理方法的基础上，若消息处理请求的类型为消费消息请求，S14根据所述消息处理请求、所述目标队列和所述目标处理策略进行消息处理可以包括：

S141.启动第一数量个线程，所述第一数量与所述消息处理请求中包含的队列数量相同。

启动第一数量个线程是为了进行多线程处理，从而加快处理速度。

S142.每个所述线程分别执行所述目标处理策略，以从所述目标队列中获取待消费消息。

S143.将所述待消费消息发送至与所述业务方标识对应的业务方，以使所述业务方执行所述业务方对应的处理方法对所述待消费消息进行消费。

其中，目标处理策略只是将待消费消息从队列中取出，具体的消费还需有业务方进行。

在一种可能的实现方式中，将待消费消息从目标队列中取出后，通过java反射机制将待消费消息发送中消费消息请求的业务方，以使业务方采用自身的处理方法对待消费消息进行消费。

本实施例提供的一种消息处理方法，根据消息处理请求中携带的队列数量，开启同等数量的线程，根据目标处理策略采用多个线程对目标队列进行同时处理，提升了消息处理速度。

在一种可能的实现方式中，有时候待消费消息发送至业务方后，由于某些原因可能会导致消费失败，为了提高待消费消息的消费成功率，该消息处理方法还包括：

获取所述业务方对所述待消费消息的消费结果，若所述消费结果为消费失败，则将所述待消费消息再次发送至所述业务方，以使所述业务方采用所述业务方对应的处理方法对所述待消费消息进行消费，直至消费成功或预设时长内该业务方对该待消费消息的消费次数达到预设的阈值，其中预设时长和阈值均为根据需求设定的值，具体取值此处不做具体限定。

本实施例提供的消息处理方法，在对待消费消息进行消费处理时，对消费结果进行检测，若消费失败则重新消费该待消费消息，提高了待消费消息的消费成功率。

一个具体的例子

如图4所示，接收到业务方发送的生产消息请求时，获取生产消息请求中携带的生产参数(例如队列名称、队列类型、取模字段、具体的消息等)，从预设的队列配置信息中获取与队列名称对应的相关配置信息(队列名称对应的队列数量等)，根据生产参数和相关配置信息组装出目标队列名称，然后根据队列类型确定要调用的方法，若队列类型为redis，则调用的方法为rpush方法，若队列类型为rocketMq，则调用的方法为asyncSend方法。

接收到业务方发送的消费消息请求后，获取消费消息请求中携带的消费参数(例如队列名称、队列数量、取模字段、队列类型、消费消息对应的业务方的名称及业务方对应的处理方法等参数)，从预设的队列配置信息中获取与队列名称对应的相关配置信息(队列名称对应的队列数量等)，然后根据队列类型确定要调用的方法，若队列类型为redis，则调用的方法为blpop方法获取待消费消息，若队列类型为rocketMq，则调用的方法为poll方法获取待消费消息，将获取的待消费消息发送至用于消费该待消费消息的业务方，以使该业务方执行具体用于消费该待消费消息的方法对该消费消息进行消费。

基于与上述消息处理方法相同的发明构思，本发明实施例还提供了一种消息处理装置，如图5所示，该装置可以包括：

接收模块501，用于接收消息处理请求，所述消息处理请求包含消息处理请求的类型、队列名称和队列类型；

目标队列确定模块502，用于根据所述队列名称和队列类型确定与所述消息处理请求对应的目标队列；

目标处理策略确定模块503，用于根据所述消息处理请求的类型和队列类型，从预设的处理策略中确定与所述消息处理请求对应的目标处理策略；

处理模块504，用于根据所述消息处理请求、所述目标队列和所述目标处理策略进行消息处理。

在一种可能的实现方式中，所述消息处理请求包含还取模字段；

所述目标队列确定模块502，具体用于：

采用预设的转换算法将所述取模字段转换为数字；

获取预设的队列配置信息中包含的所述队列名称对应的队列数量；

利用所述队列数量对所述数字进行求余计算，得到所述数字的余数；

利用所述队列名称和所述余数组成目标队列名称；

根据所述目标队列名称和所述队列类型确定目标队列。

在一种可能的实现方式中，所述目标处理策略确定模块503，具体用于：

根据预设的处理策略与消息处理请求的类型和队列类型之间的对应关系，从预设的处理策略中确定与所述消息处理请求中包含的消息处理请求的类型和队列类型对应的处理策略，作为与所述消息处理请求对应的目标处理策略。

在一种可能的实现方式中，若所述消息处理请求的类型为生产消息请求，所述消息处理请求还包含具体的消息；

所述处理模块504，具体用于：

执行所述目标处理策略，以将所述消息处理请求中包含的具体的消息存储至所述目标队列中。

在一种可能的实现方式中，若所述消息处理请求的类型为消费消息请求，所述消息处理请求还包含队列数量、业务方标识以及业务方对应的处理方法，所述业务方为发送所述消费消息请求的应用程序；

所述处理模块504，具体用于：

启动第一数量个线程，所述第一数量与所述消息处理请求中包含的队列数量相同；

每个所述线程分别执行所述目标处理策略，以从所述目标队列中获取待消费消息；

将所述待消费消息发送至与所述业务方标识对应的业务方，以使所述业务方执行所述业务方对应的处理方法对所述待消费消息进行消费。

在一种可能的实现方式中，所述装置还包括：

重试模块，具体用于获取所述业务方对所述待消费消息的消费结果；若所述消费结果为消费失败，则将所述待消费消息再次发送至所述业务方，以使所述业务方采用所述业务方对应的处理方法对所述待消费消息进行消费，直至消费成功或预设时长内该业务方对该待消费消息的消费次数达到预设的阈值。

如图6所示，本实施例公开一种电子设备，包括：包括处理器601、通信接口602、存储器603和通信总线604，其中，处理器601，通信接口602，存储器603通过通信总线604完成相互间的通信；

存储器603，用于存放计算机程序；

处理器601，用于执行存储器303上所存放的程序时，实现如下步骤：

接收消息处理请求；

根据所述消息处理请求确定与所述消息处理请求对应的目标队列；

从预设的队列配置信息中确定与所述目标队列对应的目标队列配置信息；

根据所述消息处理请求和所述目标队列配置信息，执行预设的与所述消息处理请求对应的处理策略。

上述电子设备提到的通信总线604可以是外设部件互连标准(PeripheralComponent Interconnect，简称PCI)总线或扩展工业标准结构(Extended IndustryStandard Architecture，简称EISA)总线等。该通信总线604可以分为地址总线、数据总线、控制总线等。为便于表示，图6中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

通信接口602用于上述计算机设备与其他设备之间的通信。

存储器603可以包括随机存取存储器(Random Access Memory，简称RAM)，也可以包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。可选的，存储器还可以是至少一个位于远离前述处理器的存储装置。

上述的处理器601可以是通用处理器，包括中央处理器(Central ProcessingUnit，简称CPU)、网络处理器(Network Processor，简称NP)等；还可以是数字信号处理器(Digital Signal Processing，简称DSP)、专用集成电路(Application SpecificIntegrated Circuit，简称ASIC)、现场可编程门阵列(Field-Programmable Gate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

本发明实施例还提供一种可读存储介质，所述可读存储介质存储计算机指令，所述计算机指令使所述计算机执行各方法实施例所提供的方法，例如包括：

接收消息处理请求；

根据所述消息处理请求确定与所述消息处理请求对应的目标队列；

从预设的队列配置信息中确定与所述目标队列对应的目标队列配置信息；

根据所述消息处理请求和所述目标队列配置信息，执行预设的与所述消息处理请求对应的处理策略。

本发明实施例在具体实现时，可以参阅上述各个实施例，具有相应的技术效果。

可以理解的是，本文描述的这些实施例可以用硬件、软件、固件、中间件、微码或其组合来实现。对于硬件实现，处理单元可以实现在一个或多个专用集成电路(ApplicationSpecific Integrated Circuits，ASIC)、数字信号处理器(Digital Signal Processing，DSP)、数字信号处理设备(DSP Device，DSPD)、可编程逻辑设备(Programmable LogicDevice，PLD)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)、通用处理器、控制器、微控制器、微处理器、用于执行本申请所述功能的其它电子单元或其组合中。

对于软件实现，可通过执行本文所述功能的单元来实现本文所述的技术。软件代码可存储在存储器中并通过处理器执行。存储器可以在处理器中或在处理器外部实现。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

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

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

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

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

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (12)

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

接收消息处理请求，所述消息处理请求包含消息处理请求的类型、队列名称和队列类型；

根据所述队列名称和队列类型确定与所述消息处理请求对应的目标队列；

根据所述消息处理请求的类型和队列类型，从预设的处理策略中确定与所述消息处理请求对应的目标处理策略；

根据所述消息处理请求、所述目标队列和所述目标处理策略进行消息处理。

2.根据权利要求1所述的方法，其特征在于，所述消息处理请求包含还取模字段；

根据所述队列名称和队列类型确定与所述消息处理请求对应的目标队列，包括：

采用预设的转换算法将所述取模字段转换为数字；

获取预设的队列配置信息中包含的所述队列名称对应的队列数量；

利用所述队列数量对所述数字进行求余计算，得到所述数字的余数；

利用所述队列名称和所述余数组成目标队列名称；

根据所述目标队列名称和所述队列类型确定目标队列。

3.根据权利要求1所述的方法，其特征在于，根据所述消息处理请求的类型和队列类型，从预设的处理策略中确定与所述消息处理请求对应的目标处理策略，包括：

根据预设的处理策略与消息处理请求的类型和队列类型之间的对应关系，从预设的处理策略中确定与所述消息处理请求中包含的消息处理请求的类型和队列类型对应的处理策略，作为与所述消息处理请求对应的目标处理策略。

4.根据权利要求1所述的方法，其特征在于，若所述消息处理请求的类型为生产消息请求，所述消息处理请求还包含具体的消息；

根据所述消息处理请求、所述目标队列和所述目标处理策略进行消息处理，包括：

执行所述目标处理策略，以将所述消息处理请求中包含的具体的消息存储至所述目标队列中。

5.根据权利要求1所述的方法，其特征在于，若所述消息处理请求的类型为消费消息请求，所述消息处理请求还包含队列数量、业务方标识以及业务方对应的处理方法，所述业务方为发送所述消费消息请求的应用程序；

根据所述消息处理请求、所述目标队列和所述目标处理策略进行消息处理，包括：

启动第一数量个线程，所述第一数量与所述消息处理请求中包含的队列数量相同；

每个所述线程分别执行所述目标处理策略，以从所述目标队列中获取待消费消息；

将所述待消费消息发送至与所述业务方标识对应的业务方，以使所述业务方执行所述业务方对应的处理方法对所述待消费消息进行消费。

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

获取所述业务方对所述待消费消息的消费结果；

若所述消费结果为消费失败，则将所述待消费消息再次发送至所述业务方，以使所述业务方采用所述业务方对应的处理方法对所述待消费消息进行消费，直至消费成功或预设时长内该业务方对该待消费消息的消费次数达到预设的阈值。

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

接收模块，用于接收消息处理请求，所述消息处理请求包含消息处理请求的类型、队列名称和队列类型；

目标队列确定模块，用于根据所述队列名称和队列类型确定与所述消息处理请求对应的目标队列；

目标处理策略确定模块，用于根据所述消息处理请求的类型和队列类型，从预设的处理策略中确定与所述消息处理请求对应的目标处理策略；

处理模块，用于根据所述消息处理请求、所述目标队列和所述目标处理策略进行消息处理。

8.根据权利要求7所述的装置，其特征在于，所述消息处理请求包含还取模字段；

所述目标队列确定模块，具体用于：

采用预设的转换算法将所述取模字段转换为数字；

获取预设的队列配置信息中包含的所述队列名称对应的队列数量；

利用所述队列数量对所述数字进行求余计算，得到所述数字的余数；

利用所述队列名称和所述余数组成目标队列名称；

根据所述目标队列名称和所述队列类型确定目标队列。

9.根据权利要求7所述的装置，其特征在于，所述目标处理策略确定模块，具体用于：

根据预设的处理策略与消息处理请求的类型和队列类型之间的对应关系，从预设的处理策略中确定与所述消息处理请求中包含的消息处理请求的类型和队列类型对应的处理策略，作为与所述消息处理请求对应的目标处理策略。

10.根据权利要求7所述的装置，其特征在于，若所述消息处理请求的类型为生产消息请求，所述消息处理请求还包含具体的消息；

所述处理模块，具体用于：

执行所述目标处理策略，以将所述消息处理请求中包含的具体的消息存储至所述目标队列中。

11.根据权利要求7所述的装置，其特征在于，若所述消息处理请求的类型为消费消息请求，所述消息处理请求还包含队列数量、业务方标识以及业务方对应的处理方法，所述业务方为发送所述消费消息请求的应用程序；

所述处理模块，具体用于：

启动第一数量个线程，所述第一数量与所述消息处理请求中包含的队列数量相同；

每个所述线程分别执行所述目标处理策略，以从所述目标队列中获取待消费消息；

将所述待消费消息发送至与所述业务方标识对应的业务方，以使所述业务方执行所述业务方对应的处理方法对所述待消费消息进行消费。

12.根据权利要求11所述的装置，其特征在于，所述装置还包括：

重试模块，具体用于获取所述业务方对所述待消费消息的消费结果；若所述消费结果为消费失败，则将所述待消费消息再次发送至所述业务方，以使所述业务方采用所述业务方对应的处理方法对所述待消费消息进行消费，直至消费成功或预设时长内该业务方对该待消费消息的消费次数达到预设的阈值。

Images