CN112667414A - 基于消息队列的消息消费方法、装置、计算机设备及介质 - Google Patents

Abstract

本申请公开了一种基于消息队列的消息消费方法、装置、计算机设备及介质，涉及云技术领域，所述方法包括：通过消息队列获取生产者的任务数据，将消息队列中的任务数据经过序列化解析，以得到序列任务，监测每一次从消息队列中取出序列任务进行异步消费的处理，若监测到消费异常消息或者没有接收到序列任务的消费处理消息，则执行异常处理，即将消费异常消息从消息队列中筛选出来，并对消费异常消息进行异常处理，减少了消费异常消息阻塞的问题，提高了消息的投递和消费性能，由于消费异常消息的监听可应用于各业务场景中，即共用一套代码，减少了开发工作量。此外，本申请还涉及区块链技术，用户交易数据存储于区块链中，提高了交易数据的安全性。

Description

基于消息队列的消息消费方法、装置、计算机设备及介质

技术领域

本申请涉及云技术领域，尤其涉及基于消息队列的消息消费方法、装置、计算机设备及介质。

背景技术

MQ(Message Queue)消息队列，是基础数据结构中“先进先出”的一种数据机构。指把要传输的数据(消息)放在队列中，用队列机制来实现消息传递——生产者产生消息并把消息放入队列，然后由消费者去处理。消费者可以到指定队列拉取消息，或者订阅相应的队列，由MQ服务端给其推送消息。

在电商促销活动时，由于同一时刻客户端发起的订单数量剧增，使得消息队列无法同时存放过多的与订单相关的操作消息，操作消息可以是每个订单成功下单的短信通知操作，另外，消息队列生产者和消费者大部分都是单例，当消息过多的时候，会造成消息队列阻塞，而无法高性能投递和消费，同时，当消息过多的时候，对每个消息进行业务逻辑的处理时需要编写对应的逻辑代码，加大开发工作量。

发明内容

本申请实施例的目的在于提出一种基于消息队列的消息消费方法，以解决消息队列在消息过多时存在投递和消费性能低，以及所带来的开发工作量大的问题。

为了解决上述技术问题，本申请实施例提供一种基于消息队列的消息消费方法，应用于消费者，包括如下步骤：

通过消息队列获取生产者的任务数据；

将所述消息队列中的所述任务数据经过序列化解析，以得到序列任务；

监测每一次从所述消息队列中取出所述序列任务进行异步消费的处理，若监测到消费异常消息或者没有接收到所述序列任务的消费处理消息，则执行异常处理。

进一步地，通过消息队列获取生产者中的任务数据包括：

通过所述生产者将客户端输入的请求信息生成任务消息；

将所述任务消息进行预处理得到符合所述消息队列要求的数据格式，以得到生产者实例；

将预处理后的生产者实例进行容器化处理，并将得到的任务实例发送到所述消息队列中。

进一步地，若监测到消费异常消息或者没有接收到所述序列任务的消费处理消息包括：

若所述序列任务中的消息否定确定或者拒绝，且未设置重回所述消息队列，则确定为没有接收到所述序列任务的消费处理消息；

若所述序列任务中的消息在消息服务器存活的时间超过了预设的的生存时间值，则确定为消费异常消息；

若所述序列任务中的消息量大于预设的数据量，则确定为消费异常消息。

进一步地，述若所述序列任务中的消息量大于预设的数据量，则确定为消费异常消息之后，所述方法还包括：

对指定消息数据库进行编号，得到标记数据库，其中，所述消息数据库至少为2个；

根据所述消费异常消息从所述标记数据库中确定目标数据库对应的编号；

根据所述目标数据库对应的编号，将所述消费异常消息通过路由转发到目标数据库中。

进一步地，对指定消息数据库进行编号，得到标记数据库包括：

获取所述指定消息数据库的数据库信息，其中，所述数据库信息包括互联网协议地址和所述指定消息数据库的服务器数量；

对所述互联网协议地址进行哈希取值，以得到地址哈希值；

根据所述地址哈希值和所述服务器数量，得到携带编号的标记数据库。

进一步地，根据所述消费异常消息从所述标记数据库中确定目标数据库对应的编号包括：

将所述消费异常消息进行哈希取值，以得到消费哈希值；

根据所述消费哈希值与所述服务器数量，从所述标记数据库中确定目标数据库对应的编号。

进一步地，监测每一次从所述消息队列中取出所述序列任务进行异步消费的处理，若监测到消费异常消息或者没有接收到所述序列任务的消费处理消息，则执行异常处理包括：

将所述消费异常消息或没有接收到所述序列任务的消费处理消息作为异常消息丢进配置好的死信队列中；

通过监听所述死信队列中的异常消息，并执行相应的异常处理。

为了解决上述技术问题，本申请实施例还提供一种基于消息队列的消息消费装置，所述基于消息队列的消息消费装置包括：

获取模块，用于通过消息队列获取生产者的任务数据；

序列化模块，用于将所述消息队列中的所述任务数据经过序列化解析，以得到序列任务；

监测处理模块，用于监测每一次从所述消息队列中取出所述序列任务进行异步消费的处理，若监测到消费异常消息或者没有接收到所述序列任务的消费处理消息，则执行异常处理。

进一步的，所述任务数据包括任务施例，所述获取模块包括：

生成单元，用于通过所述生产者将客户端输入的请求信息生成任务消息；

预处理单元，用于将所述任务消息进行预处理得到符合所述消息队列要求的数据格式，以得到生产者实例；

容器处理单元，用于将预处理后的生产者实例进行容器化处理，并将得到的任务实例发送到所述消息队列中。

进一步地，监测处理模块包括：

第一确定单元，用于若所述序列任务中的消息否定确定或者拒绝，且未设置重回所述消息队列，则确定为没有接收到所述序列任务的消费处理消息；

第二确定单元，用于若所述序列任务中的消息在消息服务器存活的时间超过了预设的的生存时间值，则确定为消费异常消息；

第三确定单元，用于若所述序列任务中的消息量大于预设的数据量，则确定为消费异常消息。

为了解决上述技术问题，本申请实施例还提供一种计算机设备，包括存储器和处理器，所述存储器中存储有计算机可读指令，所述处理器执行所述计算机可读指令时实现上述基于消息队列的消息消费方法的步骤。

为了解决上述技术问题，本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机可读指令，所述计算机可读指令被处理器执行时实现上述的基于消息队列的消息消费方法的步骤。

与现有技术相比，本申请实施例主要有以下有益效果：通过消息队列获取生产者的任务数据，将消息队列中的任务数据经过序列化解析，以得到序列任务，监测每一次从消息队列中取出序列任务进行异步消费的处理，若监测到消费异常消息或者没有接收到序列任务的消费处理消息，则执行异常处理，即将消费异常消息从消息队列中筛选出来，并对消费异常消息进行异常处理，减少了消费异常消息阻塞的问题，提高了消息的投递和消费性能，由于消费异常消息的监听可应用于各业务场景中，即共用一套代码，减少了开发工作量。

附图说明

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

图1是本申请可以应用于其中的示例性系统架构图；

图2根据本申请的基于消息队列的消息消费方法的一个实施例的流程图；

图3是根据本申请的基于消息队列的消息消费装置的一个实施例的结构示意图；

图4是根据本申请的计算机设备的一个实施例的结构示意图。

具体实施方式

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同；本文中在申请的说明书中所使用的术语只是为了描述具体的实施例的目的，不是旨在于限制本申请；本申请的说明书和权利要求书及上述附图说明中的术语“包括”和“具有”以及它们的任何变形，意图在于覆盖不排他的包含。本申请的说明书和权利要求书或上述附图中的术语“第一”、“第二”等是用于区别不同对象，而不是用于描述特定顺序。

在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。

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

如图1所示，系统架构100可以包括终端设备101、102、103，网络104和服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备101、102、103通过网络104与服务器105交互，以接收或发送消息等。终端设备101、102、103上可以安装有各种通讯客户端应用，例如网页浏览器应用、购物类应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等。

终端设备101、102、103可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、电子书阅读器、MP3播放器(Moving Picture ExpertsGroup Audio Layer III，动态影像专家压缩标准音频层面3)、MP4(Moving PictureExperts Group Audio Layer IV，动态影像专家压缩标准音频层面4)播放器、膝上型便携计算机和台式计算机等等。

服务器105可以是提供各种服务的服务器，例如对终端设备101、102、103上显示的页面提供支持的后台服务器。

需要说明的是，本申请实施例所提供的基于消息队列的消息消费方法一般由服务器/终端设备执行，相应地，基于消息队列的消息消费装置一般设置于服务器/终端设备中。

应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

继续参考图2，示出了根据本申请的基于消息队列的消息消费的方法的一个实施例的流程图。所述的基于消息队列的消息消费方法，包括以下步骤：

S201：通过消息队列获取生产者的任务数据。

在本实施例中，基于消息队列的消息消费方法运行于其上的电子设备(例如图1所示的服务器/终端设备)可以通过有线连接方式或者无线连接方式。需要指出的是，上述无线连接方式可以包括但不限于3G/4G连接、WiFi连接、蓝牙连接、WiMA基于消息队列的消息消费连接、Zigbee连接、UWB(ultra wideband)连接、以及其他现在已知或将来开发的无线连接方式。

进一步地，本申请实施例中的执行主体为消费者，通过调用各个业务代码模块实现对消息的监听和判断，以完成生产者将任务数据投递到消费者，使消费者完成对消息的处理过程。其中，业务代码模块可以但不限于消费者监听容器、消费者幂等性保障拦截器、消费存储路由选择器、消息异步处理器以及消息存储幂等服务以及消息异常监听器等。消费者监听容器用于对消息队列中的数据进行池化；消费者幂等性保障拦截器用于判断消息是否已经消费过进行保障拦截处理；消息存储幂等服务用于消息的幂等处理，保证消息消费的幂等性；消费存储路由选择器用于将任务数据转发到对应的数据库中；消息异步处理器用于消息队列异步消费处理，以保证消费的高性能；消息异常监听器用于监听消息队列中数据的运行状态是否异常。

进一步地，消息队列(Message Queue，MQ)，是基础数据结构中“先进先出”的一种数据结构。一般用来解决应用解耦，异步消息，流量削峰等问题，实现高性能，高可用，可伸缩和最终一致性架构。需要特别说明的是，MQ只用来传递上游任务执行完成的消息，并不用于传递真正的输入输出数据。

在本实施例的一些可选的实现方式中，任务数据包括任务施例，步骤S201，即通过消息队列获取生产者的任务数据，上述电子设备还可以执行以下步骤：

通过生产者将客户端输入的请求信息生成任务消息；

将任务消息进行预处理得到符合消息队列要求的数据格式，以得到生产者实例；

将预处理后的生产者实例进行容器化处理，并将得到的任务实例发送到消息队列中。

具体地，请求信息可以是用户提交的订单信息，例如购买的物品信息、物品价格、提交订单信息等。生产者将该请求信息转化成消息队列所要求的数据格式，例如，数据格式可以是数值方式、表单方式或者是链接方式，并在转化过程中可以对请求信息进行时间顺序设置，例如可以是手动消息顺序设置、延迟消息设置或者顺序消息设置等，以生成生产者实例，任务消息除了包括订单信息还包括该订单信息被设定的处理时间。

具体地，容器化处理是应用程序级别的虚拟化，允许单个内核上有多个独立的用户空间实例，这些用户空间实例称为容器。容器提供了将应用程序的代码、运行时、系统工具、系统库和配置打包到一个实例中的标准方法。容器共享一个内核(操作系统)，它安装在硬件上。容器的好处是轻便，容器占用的服务器空间比虚拟机少，通常只需几秒钟即可启动。弹性容器具有高弹性，不需要分配给定数量的资源。这意味着容器能够更有效地动态使用服务器中的资源。当一个容器上的需求减少时，释放额外的资源供其他容器使用。容器化允许创建密集的环境，其中主机服务器的资源被充分利用但不被过度利用。与传统虚拟化相比，容器化允许更密集的环境容器不需要托管自己的操作系统。性能当资源压力很大时，应用程序的性能远远高于使用虚拟机管理程序的容器。即将预处理后的生产者实例进行容器化处理，得到占比内存相对较低的任务实例，并将该任务实例发送到消息队列中，由于容器处理后的任务实例占比内存小，有利于提高传输效率。

S202：将消息队列中的任务数据经过序列化解析，以得到序列任务。

具体地，序列化解析是指堆内存中的java对象数据转换成可取用格式，并将转换后的java对象数据存储到磁盘文件中，或者传递给其他网络节点(网络传输)，这个过程称为序列化。通常是指将数据结构或对象转化成二进制的过程。即将对象转化为二进制，用于保存，或者网络传输。序列化解析主要应用的场景包括：可以将内存中的对象保存到一个文件中或者数据库中时候；或者可以用套接字在网络上传送对象的时候；或者想通过RMI传输对象时。因此，通过序列化解析得到的序列任务可以更高效地完成投递过程。

S203：监测每一次从消息队列中取出序列任务进行异步消费的处理，若监测到消费异常消息或者没有接收到序列任务的消费处理消息，则执行异常处理。

在本申请实施例中，当监听到消息队列积压了几百万到上千万的数据，即消费者此时需要花费更长的时间来处理这些数据，此种情况下(消息积压情况)的数据均作为消费异常消息，此时的异常处理操作为临时紧急扩容，通过临时扩充部署消费者，使得每一批消费者消费一个消息队列的数据，以快速消费完积压的数据；消费者导致的消息丢失(即没有接收到序列任务的消费处理消息)，一般由于数据还未处理成功却提前通知消息队列消息已经处理成功了，此时禁止自动提交或异步操作即可；生产者和消息队列自身导致的消息丢失，可以使用confirm模式(确认模式)避免消息丢失，即生产者将信道设置成confirm模式，一旦信道进入confirm模式，所有在该信道上面发布的消息都将会被指派一个唯一的ID，一旦消息被投递到所有匹配的队列之后，broker(消息队列服务器实体)就会发送一个确认给生产者(包含消息的唯一ID)，这就使得生产者知道消息已经正确到达目的队列；针对不同的异常情况还提供了补偿机制进行处理。

通过消息队列获取生产者的任务数据，将消息队列中的任务数据经过序列化解析，以得到序列任务，监测每一次从消息队列中取出序列任务进行异步消费的处理，若监测到消费异常消息或者没有接收到序列任务的消费处理消息，则执行异常处理，即将消费异常消息从消息队列中筛选出来，并对消费异常消息进行异常处理，减少了消费异常消息阻塞的问题，提高了消息的投递和消费性能，由于消费异常消息的监听可应用于各业务场景中，即共用一套代码，减少了开发工作量。

需要强调的是，为进一步保证上述用户提交的订单信息的私密和安全性，上述订单信息例如用户购买的保险订单、提交订单时间等经过加密处理后，并存储于一区块链的节点中。

本申请所指区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链(Blockchain)，本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一批次网络交易的信息，用于验证其信息的有效性(防伪)和生成下一个区块。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层等。

进一步地，将所述消息队列中的序列任务进行异步消费处理之前，通过监听序列任务的池化和/或根据消费者幂等性来判断所述序列任务是否已经消费。

其中，池化是指把一些能够复用的东西(比如说数据库连接、线程)放到池中，避免重复创建、销毁的开销，从而极大提高性能。在开发过程中会用到很多的连接池，像是数据库连接池、HTTP连接池、Redis连接池等等。对于没有状态的对象(例如String)，在重复使用之前，无需进行任何处理；对于有状态的对象(例如StringBuffer)，在重复使用之前，就需要把它们恢复到等同于刚刚生成时的状态。由于条件的限制，恢复某个对象的状态的操作不可能实现了的话，就得把这个对象抛弃，改用新创建的实例了。

因此，监听序列任务的池化可以避免重复创建、销毁的开销，从而极大提高性能。

消费者幂等性是指一个接口多次发起同一个请求，必须保证操作只能执行一次。比如订单接口，不能多次创建订单；支付接口，重复支付同一笔订单只能扣一次钱，支付端口回调接口，可能会多次回调，必须处理重复回调；普通表单提交接口，因为网络超时等原因多次点击提交，只能成功一次等等。通过消费者幂等性保障拦截器判断请求是否重复，可以减少执行次数。

没有接收到所述序列任务的消费处理消息可以是没有在Broker(消息队列服务器实体)中消费到消息。此处的异常处理可以是根据业务需求进行设置处理，例如监听到对同一订单有重复支付的消息时，则只执行一次扣钱操作，并将其余重复支付操作的消息不做处理。

在本实施例的一些可选的实现方式中，步骤S203，即若监测到消费异常消息或者没有接收到所述序列任务的消费处理消息，上述电子设备还可以执行以下步骤：

若序列任务中的消息否定确定或者拒绝，且未设置重回消息队列则确定为没有接收到序列任务的消费处理消息；

若序列任务中的消息在消息服务器存活的时间超过了预设的的生存时间值，则确定为消费异常消息；

若序列任务中的消息量大于预设的数据量，则确定为消费异常消息。

其中，预设的生存时间和预设的数据量可以根据实际情况进行设置。

将消费异常消息或没有接收到序列任务的消费处理消息作为异常消息丢进配置好的死信队列中；

通过监听死信队列中的异常消息，并执行相应的异常处理。

当序列任务中的消息量过大超过了消息队列的长度，再进行消息投递，消息队列无法容纳新的消息就自动丢失该消息了。

具体地，将上述三种情况包括的消费异常消息或者没有接收到所述序列任务的消费处理消息丢进配置好的死信队列中，通过监听死信队列中的异常消息，并执行异常消息的处理。

进一步地，正常情况下无法被消费的消息称为死信消息(Dead-Letter Message)，存储死信消息的特殊队列称为死信队列(Dead-Letter Queue，DLQ)。当消费者执行同一消息达到最大重试次数后，若消费依然失败，则表明消费者在正常情况下无法正确地消费该消息，将其发送到该消费者对应的特殊队列中，这个特殊队列就是DLQ。对新建的队列，或存量的队列，都可以启用死信队列。例如，某条消息被多次消费后却未被删除，一般是由于该消息未被正确消费，可能存在问题需要回溯定位。此时可以设置最大接收次数，超额后该消息会被淘汰到指定的死信队列，便于后续问题发现。

进一步地，当序列任务成功投递到消费者，消费者能对该消息正常执行，即可确认该序列任务完成完整投递。

通过消息队列获取生产者的任务数据，将消息队列中的任务数据经过序列化解析，以得到序列任务，监测每一次从消息队列中取出序列任务进行异步消费的处理，若监测到消费异常消息或者没有接收到序列任务的消费处理消息，则执行异常处理，即将消费异常消息从消息队列中筛选出来，并对消费异常消息进行异常处理，减少了消费异常消息阻塞的问题，提高了消息的投递和消费性能，由于消费异常消息的监听可应用于各业务场景中，即共用一套代码，减少了开发工作量。

本实施例的一些可选的实现方式中，若序列任务中的消息量大于预设的数据量，则确定为消费异常消息之后，所述方法还包括：

对指定消息数据库进行编号，得到标记数据库，其中，消息数据库至少为2个；

根据消费异常消息从标记数据库中确定目标数据库对应的编号；

根据目标数据库对应的编号，将消费异常消息通过路由转发到目标数据库中。

其中，对指定消息数据库进行编号，得到标记数据库包括：

获取指定消息数据库的数据库信息，其中，所述数据库信息包括互联网协议地址和指定消息数据库的服务器数量；

对互联网协议地址进行哈希取值，以得到地址哈希值；

根据地址哈希值和服务器数量，得到携带编号的标记数据库。

具体地，上述获取携带编号的标记数据库可采用公式(1)：

DB＝hash(IP)％count(DB)公式(1)

其中，DB表示标记数据库，hash为哈希函数，IP为指定消息数据库的互联网协议地址(即IP地址)，count(DB)为指定消息数据库的服务器数量，％为取模。由于哈希函数计算后的消息所占的内存空间被压缩，减少了内存损耗，进而提高了存储效率。

进一步地，将得到的每个标记数据库的编号和对应的每个标记数据库的互联网协议地址保存在数据表中。

需要说明的是，由于哈希函数可以将一个数据转换为一个标志，这个标志和源数据的每一个字节都有十分紧密的关系，因此通过哈希函数预先建立包括每个标记数据库编号的数据表，当数据表存在和所要查询的标记数据库编号相同时，则必定可根据该标记数据库编号找到该标记数据库的存储位置上(即互联网协议地址)。因此通过上述公式可以获取每个标记数据库对应的唯一编号，有利于后续消息所存放标记数据库对应的IP地址的查询和准确投递。

其中，根据消费异常消息从标记数据库中确定目标数据库对应的编号包括：

将消费异常消息进行哈希取值，以得到消费哈希值；

根据消费哈希值与服务器数量，从标记数据库中确定目标数据库对应的编号。

上述确定目标数据库对应的编号的过程可采用公式(2)得到：

db＝hash(Message)％count(DB)公式(2)

其中，db表示目标数据库，Message表示消费异常消息地址，count(DB)为指定消息数据库的服务器数量。

具体地，哈希函数把任意长度的输入(又叫做预映射pre-image)通过散列算法变换成固定长度的输出，该输出就是散列值。简单的说就是一种将任意长度的消息压缩到某一固定长度的消息摘要的函数，使得经过哈希函数计算后的消息所占的内存空间被压缩，减少内存损耗。

进一步地，消息地址经过哈希计算得到唯一的目标编号，根据预先构建的数据表可以快速定位到目标编号所在的IP地址，使得经过哈希处理后的消息不仅占内存空间小，并且能更精准、高效地发送至目标数据库中。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机可读指令来指令相关的硬件来完成，该计算机可读指令可存储于一计算机可读取存储介质中，该可读指令在执行时，可包括如上述各方法的实施例的流程。其中，前述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)等非易失性存储介质，或随机存储记忆体(Random Access Memory，RAM)等。

应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

进一步参考图3，作为对上述图2所示方法的实现，本申请提供了一种基于消息队列的消息消费装置的一个实施例，该装置实施例与图2所示的方法实施例相对应，该装置具体可以应用于各种电子设备中。

如图3所示，本实施例所述的基于消息队列的消息消费装置包括：获取模块301、序列化模块302以及监测处理模块303。其中：

获取模块301，用于通过消息队列获取生产者的任务数据；

序列化模块302，用于将消息队列中的任务数据经过序列化解析，以得到序列任务；

监测处理模块303，用于监测每一次从消息队列中取出序列任务进行异步消费的处理，若监测到消费异常消息或者没有接收到序列任务的消费处理消息，则执行异常处理。

通过获取模块获取任务数据，经过序列化模块对任务数据的序列化解析，以得到序列任务，通过监听处理模块监听序列任务中将消费异常消息从消息队列中筛选出来，并对其异常处理，减少了消费异常消息阻塞的问题，提高了消息的投递和消费性能，由于消费异常消息的监听可应用于各业务场景中，即共用一套代码，减少了开发工作量。

进一步的，任务数据包括任务施例，获取模块301包括：

生成单元，用于通过生产者将客户端输入的请求信息生成任务消息；

预处理单元，用于将任务消息进行预处理得到符合消息队列要求的数据格式，以得到生产者实例；

容器处理单元，用于将预处理后的生产者实例进行容器化处理，并将得到的任务实例发送到消息队列中。

进一步地，监测处理模块303包括：

第一确定单元，用于若序列任务中的消息否定确定或者拒绝，且未设置重回消息队列，则确定为没有接收到序列任务的消费处理消息；

第二确定单元，用于若序列任务中的消息在消息服务器存活的时间超过了预设的的生存时间值，则确定为消费异常消息；

第三确定单元，用于若序列任务中的消息量大于预设的数据量，则确定为消费异常消息。

进一步地，监测处理模块303还包括：

编号单元，用于对指定消息数据库进行编号，得到标记数据库，其中，消息数据库至少为2个；

确定目标单元，用于根据消费异常消息从标记数据库中确定目标数据库对应的编号；

转发单元，用于根据目标数据库对应的编号，将消费异常消息通过路由转发到目标数据库中。

进一步地，编号单元包括：

获取子单元，用于获取指定消息数据库的数据库信息，其中，所述数据库信息包括互联网协议地址和指定消息数据库的服务器数量；

哈希子单元，用于对互联网协议地址进行哈希取值，以得到地址哈希值；

标记子单元，用于根据地址哈希值和服务器数量，得到携带编号的标记数据库。

进一步地，确定目标单元包括：

消费哈希子单元，用于将消费异常消息进行哈希取值，以得到消费哈希值；

目标编号子单元，用于根据消费哈希值与服务器数量，从标记数据库中确定目标数据库对应的编号。

进一步地，监测处理模块303还包括：

死信队列单元，用于将消费异常消息或没有接收到序列任务的消费处理消息作为异常消息丢进配置好的死信队列中；

异常处理单元，用于通过监听死信队列中的异常消息，并执行相应的异常处理。

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

为解决上述技术问题，本申请实施例还提供计算机设备。具体请参阅图4，图4为本实施例计算机设备基本结构框图。

所述计算机设备4包括通过系统总线相互通信连接存储器41、处理器42、网络接口43。需要指出的是，图中仅示出了具有组件41-43的计算机设备4，但是应理解的是，并不要求实施所有示出的组件，可以替代的实施更多或者更少的组件。其中，本技术领域技术人员可以理解，这里的计算机设备是一种能够按照事先设定或存储的指令，自动进行数值计算和/或信息处理的设备，其硬件包括但不限于微处理器、专用集成电路(ApplicationSpecific Integrated Circuit，ASIC)、可编程门阵列(Field－Programmable GateArray，FPGA)、数字处理器(Digital Signal Processor，DSP)、嵌入式设备等。

所述计算机设备可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。所述计算机设备可以与用户通过键盘、鼠标、遥控器、触摸板或声控设备等方式进行人机交互。

所述存储器41至少包括一种类型的可读存储介质，所述可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或D基于消息队列的消息消费存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中，所述存储器41可以是所述计算机设备4的内部存储单元，例如该计算机设备4的硬盘或内存。在另一些实施例中，所述存储器41也可以是所述计算机设备4的外部存储设备，例如该计算机设备4上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(SecureDigital,SD)卡，闪存卡(Flash Card)等。当然，所述存储器41还可以既包括所述计算机设备4的内部存储单元也包括其外部存储设备。本实施例中，所述存储器41通常用于存储安装于所述计算机设备4的操作系统和各类应用软件，例如基于消息队列的消息消费方法的可读指令代码等。此外，所述存储器41还可以用于暂时地存储已经输出或者将要输出的各类数据。

所述处理器42在一些实施例中可以是中央处理器(Central Processing Unit，CPU)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器42通常用于控制所述计算机设备4的总体操作。本实施例中，所述处理器42用于运行所述存储器41中存储的可读指令代码或者处理数据，例如运行所述基于消息队列的消息消费方法的可读指令代码。

所述网络接口43可包括无线网络接口或有线网络接口，该网络接口43通常用于在所述计算机设备4与其他电子设备之间建立通信连接。

本申请还提供了另一种实施方式，即提供一种计算机可读存储介质，所述计算机可读存储介质存储有基于消息队列的消息消费可读指令，所述基于消息队列的消息消费可读指令可被至少一个处理器执行，以使所述至少一个处理器执行如上述的基于消息队列的消息消费方法的步骤。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本申请各个实施例所述的方法。

显然，以上所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例，附图中给出了本申请的较佳实施例，但并不限制本申请的专利范围。本申请可以以许多不同的形式来实现，相反地，提供这些实施例的目的是使对本申请的公开内容的理解更加透彻全面。尽管参照前述实施例对本申请进行了详细的说明，对于本领域的技术人员来而言，其依然可以对前述各具体实施方式所记载的技术方案进行修改，或者对其中部分技术特征进行等效替换。凡是利用本申请说明书及附图内容所做的等效结构，直接或间接运用在其他相关的技术领域，均同理在本申请专利保护范围之内。

Claims (10)

1.一种基于消息队列的消息消费方法，应用于消费者，其特征在于，所述方法包括：

通过消息队列获取生产者的任务数据；

将所述消息队列中的所述任务数据经过序列化解析，以得到序列任务；

监测每一次从所述消息队列中取出所述序列任务进行异步消费的处理，若监测到消费异常消息或者没有接收到所述序列任务的消费处理消息，则执行异常处理。

2.根据权利要求1所述的基于消息队列的消息消费方法，其特征在于，所述任务数据包括任务施例，所述通过消息队列获取生产者的任务数据包括：

通过所述生产者将客户端输入的请求信息生成任务消息；

将所述任务消息进行预处理得到符合所述消息队列要求的数据格式，以得到生产者实例；

将预处理后的生产者实例进行容器化处理，并将得到的任务实例发送到所述消息队列中。

3.根据权利要求1所述的基于消息队列的消息消费方法，其特征在于，所述若监测到消费异常消息或者没有接收到所述序列任务的消费处理消息包括：

若所述序列任务中的消息否定确定或者拒绝，且未设置重回所述消息队列，则确定为没有接收到所述序列任务的消费处理消息；

若所述序列任务中的消息在消息服务器存活的时间超过了预设的生存时间值，则确定为消费异常消息；

若所述序列任务中的消息量大于预设的数据量，则确定为消费异常消息。

4.根据权利要求3所述的基于消息队列的消息消费方法，其特征在于，所述若所述序列任务中的消息量大于预设的数据量，则确定为消费异常消息之后，所述方法还包括：

对指定消息数据库进行编号，得到标记数据库，其中，所述消息数据库至少为2个；

根据所述消费异常消息从所述标记数据库中确定目标数据库对应的编号；

根据所述目标数据库对应的编号，将所述消费异常消息通过路由转发到目标数据库中。

5.根据权利要求4所述的基于消息队列的消息消费方法，其特征在于，所述对指定消息数据库进行编号，得到标记数据库包括：

获取所述指定消息数据库的数据库信息，其中，所述数据库信息包括互联网协议地址和所述指定消息数据库的服务器数量；

对所述互联网协议地址进行哈希取值，以得到地址哈希值；

根据所述地址哈希值和所述服务器数量，得到携带编号的标记数据库。

6.根据权利要求5所述的基于消息队列的消息消费方法，其特征在于，所述根据所述消费异常消息从所述标记数据库中确定目标数据库对应的编号包括：

将所述消费异常消息进行哈希取值，以得到消费哈希值；

根据所述消费哈希值与所述服务器数量，从所述标记数据库中确定目标数据库对应的编号。

7.根据权利要求1或3所述的基于消息队列的消息消费方法，其特征在于，所述监测每一次从所述消息队列中取出所述序列任务进行异步消费的处理，若监测到消费异常消息或者没有接收到所述序列任务的消费处理消息，则执行异常处理包括：

将所述消费异常消息或没有接收到所述序列任务的消费处理消息作为异常消息丢进配置好的死信队列中；

通过监听所述死信队列中的异常消息，并执行相应的异常处理。

8.一种基于消息队列的消息消费装置，其特征在于，包括：

获取模块，用于通过消息队列获取生产者的任务数据；

序列化模块，用于将所述消息队列中的所述任务数据经过序列化解析，以得到序列任务；

监测处理模块，用于监测每一次从所述消息队列中取出所述序列任务进行异步消费的处理，若监测到消费异常消息或者没有接收到所述序列任务的消费处理消息，则执行异常处理。

9.一种计算机设备，包括存储器和处理器，所述存储器中存储有计算机可读指令，所述处理器执行所述计算机可读指令时实现如权利要求1至7中任一项所述的基于消息队列的消息消费方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机可读指令，所述计算机可读指令被处理器执行时实现如权利要求1至7中任一项所述的基于消息队列的消息消费方法的步骤。

Images