微服务架构下的消息消费方法、装置和存储介质

摘要

本申请公开了一种微服务架构下的消息消费方法、装置和存储介质，涉及互联网技术领域，所述方法包括：在本地的消息表中存储消息，将所述消息的状态标记为未提交，所述消息表中包括消息的消息标识、消息内容以及消息状态；在所述消息表中存储所述消息后，发送所述消息至消息协商器MQ broker；将所述消息表中的所述消息的消息状态修改为未确认。解决了现有技术中消息可能会丢失的问题，达到了即使消息发送过程中丢失但是由于生成端本地存储有该消息也可以再次找到该消息的效果。

说明书

技术领域

本发明涉及一种微服务架构下的消息消费方法、装置和存储介质，属于互联网技术领域。

背景技术

在微服务架构体系下，高并发的业务场景中，引入MQ（Message Queue，消息队列）可以削峰填谷，很大程度上提高系统吞吐量，提升用户体验。但是高并发得发送数据的时候，不能保证数据都能发送成功（网络不稳定），也不能保证数据只消费一次（网络不稳定），客户端ACK（Acknowledge character，确认字符）信息，MQ服务器没有收到客户端的ACK信息。危害是：1、数据不能成功发送会造成数据丢失；2、重复消费，从系统角度讲会造成垃圾数据；从业务角度讲，以付款为例会造成多次支付。

发明内容

本发明的目的在于提供一种微服务架构下的消息消费方法、装置和存储介质，用于解决现有技术中存在的问题。

为达到上述目的，本发明提供如下技术方案：

根据第一方面，本发明实施例提供了一种微服务架构下的消息消费方法，所述方法包括：

在本地的消息表中存储消息，将所述消息的状态标记为未提交，所述消息表中包括消息的消息标识、消息内容以及消息状态；

在所述消息表中存储所述消息后，发送所述消息至消息协商器MQ broker；

将所述消息表中的所述消息的消息状态修改为未确认。

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

检测发送所述消息至所述MQ broker的发送次数是否达到预设次数；

若所述发送次数达到所述预设次数，则停止发送。

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

定时检测所述消息表中是否存在状态为未确认的消息；

若存在，则再次发送状态为未确认的消息至所述MQ broker。

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

接收消费端返回的确认信息，所述确认信息为所述消费端在成功消费所述消息之后返回的信息；

在接收到所述确认信息之后，将所述消息表中的所述消息的状态修改为已确认。

第二方面，提供了一种微服务架构下的消息消费方法，所述方法包括：

生成端在本地的消息表中存储消息，将所述消息的状态标记为未提交，所述消息表中包括消息的消息标识、消息内容以及消息状态；

所述生成端在所述消息表中存储所述消息后，发送所述消息至消息协商器MQ broker；

所述生成端将所述消息表中的所述消息的消息状态修改为未确认；

消费端消费所述MQ broker接收到的所述消息。

可选的，在所述消费端消费所述消息之前，所述消费端根据所述消息的消息标识检测所述消费端的本地存根中是否存在所述消息；

若存在，则不再消费；

若不存在，则所述消费端消费所述消息。

可选的，在所述消费端成功消费所述消息之后，返回确认信息至生成端；

所述生成端接收消费端返回的确认信息；

所述生成端在接收到所述确认信息之后，将所述消息表中的所述消息的状态修改为已确认。

第三方面，提供了一种微服务架构下的消息消费装置，所述装置包括存储器和处理器，所述存储器中存储有至少一条程序指令，所述处理器通过加载并执行所述至少一条程序指令以实现如第一方面或者第二方面所述的方法。

第三方面，提供了一种计算机存储介质，所述存储介质中存储有至少一条程序指令，所述至少一条程序指令被处理器加载并执行以实现第一方面或者第二方面所述的方法。

通过在本地的消息表中存储消息，将所述消息的状态标记为未提交，所述消息表中包括消息的消息标识、消息内容以及消息状态； 在所述消息表中存储所述消息后，发送所述消息至消息协商器MQ broker；将所述消息表中的所述消息的消息状态修改为未确认。也即在将消息发送至MQ broker之前存储在本地消息表中，解决了现有技术中消息可能会丢失的问题，达到了即使消息发送过程中丢失但是由于生成端本地存储有该消息也可以再次找到该消息的效果。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，并可依照说明书的内容予以实施，以下以本发明的较佳实施例并配合附图详细说明如后。

附图说明

图1为本发明一个实施例提供的微服务架构下的消息消费方法的方法流程图；

图2为本发明一个实施例提供的微服务架构下的消息消费方法的方法流程图。

具体实施方式

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

在本发明的描述中，需要说明的是，术语“中心”、“上”、“下”、“左”、“右”、“竖 直”、“水平”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。此外，术语“第一”、“第二”、“第三”仅用于描述目的，而不能理解为指示或暗示相对重要性。

在本发明的描述中，需要说明的是，除非另有明确的规定和限定，术语“安装”、“相连”、“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本发明中的具体含义。

此外，下面所描述的本发明不同实施方式中所涉及的技术特征只要彼此之间 未构成冲突就可以相互结合。

请参考图1，其示出了本申请一个实施例提供的微服务架构下的消息消费方法的方法流程图，如图1所示，所示方法包括：

步骤101，生成端在本地的消息表中存储消息，将所述消息的状态标记为未提交；

消息表可以为mongodb（基于分布式文件存储的数据库）或者mysql（关系型数据库管理系统），并且实际实现时表名可以为producer_message。所述消息表中包括消息的消息标识、消息内容以及消息状态。消息标识messageID用来在消息的生成端和消费端串联使用，根据ID（Identity document，身份标识号）找到消费端和生产端唯一的消息messageContent消息内容。

消息的状态可以包括未提交、未确认、已确认。其中，未提交表示消息未提交至消息协商器MQ broker，已确认表示消费端已成功消费该消息，未确认表示MQ broker成功接收到消息但是消费端还未消费该消息。

这也就是说，在生成端生成消息但是还未发送至MQ broker之前，消息的状态为未提交。

步骤102，所述生成端在所述消息表中存储所述消息后，发送所述消息至MQbroker；

生成端在将消息存储在消息表中之后，即可发送消息至MQ broker。

实际实现时，由于发送消息至MQ broker时，可能会发送失败，因此为了保证业务的正常执行，可以多次发送消息至MQ broker。可选的，可以统计发送消息至MQ broker的发送次数，检测发送次数是否达到预设次数，在达到预设次数时，则停止发送，反之若未达到预设次数，则继续发送。通过在发送次数达到预设次数时不再继续发送，避免了消息一直发送时可能会导致的MQ broker的空间大量占用，影响其他业务的正常运行的问题。

步骤103，所述生成端将所述消息表中的所述消息的消息状态修改为未确认；

步骤104，消费端消费所述MQ broker接收到的所述消息。

MQ broker接收到生成端发送的消息之后，消费端即可消费MQ broker中的消息。

可选的，若消费端消费成功，则上述方法还包括以下步骤：

第一，在所述消费端成功消费所述消息之后，返回确认信息至生成端；

第二，所述生成端接收消费端返回的确认信息；

第三，所述生成端在接收到所述确认信息之后，将所述消息表中的所述消息的状态修改为已确认。

这也就是说，消费端成功消费消息之后，需要回调生成端修改生成端消息表(producer message表)的状态，把状态变成已确认状态。

综上所述，通过在本地的消息表中存储消息，将所述消息的状态标记为未提交，所述消息表中包括消息的消息标识、消息内容以及消息状态； 在所述消息表中存储所述消息后，发送所述消息至消息协商器MQ broker；将所述消息表中的所述消息的消息状态修改为未确认。也即在将消息发送至MQ broker之前存储在本地消息表中，解决了现有技术中消息可能会丢失的问题，达到了即使消息发送过程中丢失但是由于生成端本地存储有该消息也可以再次找到该消息的效果。

需要说明的一点是，在上述方法中，还可以设置有定时器timer，通过timer检测，也即上述方法还可以包括：

第一，定时检测所述消息表中是否存在状态为未确认的消息；

第二，若存在，则再次发送状态为未确认的消息至所述MQ broker。

通过定时检测消息表中的未确认消息，进而再次发送未确认消息至MQ broker，一定程度上保证了业务的正常运行。另外，结合步骤102的论述可知，可以通过预设次数来限制消息的发送次数，避免了消息一直消费不成功大量的消息重复发送到MQ broker导致MQbroker 被垃圾消息填满的问题。

需要说明的，实际实现时，可能会存在消息消费成功之后状态未修改为已确认进而导致被timer重新发送至MQ broker消费端重新消费的问题，因此，在本实施例的一种可能的实施方式中，上述方法还包括：

第一，在所述消费端消费所述消息之前，所述消费端根据所述消息的消息标识检测所述消费端的本地存根中是否存在所述消息；

所述消费端的本地存根中存储有消费成功的各条消息。也即在上述步骤104之后，在消费成功后，将在消息表记录中存储该消息。可选的，可以将该消息的消息标识和消息内容关联存储。

第二，若存在，则不再消费；

第三，若不存在，则所述消费端消费所述消息。

所述消费端的本地存根中存在消息，则说明已经消费过，此时不再消费，反之，则说明未消费过，则继续消费。

在一种可能的应用场景中，请参考图2，应用程序生产者生成消息，发送消息msg至生产者消息本地存根producer message，存储消息msg并将msg状态标记为未提交。此后发送消息至MQ，应用程序消费者从MQ中拉取消息，相应的，MQ broker返回消息。应用程序消费者查询本地存根中是否存在该消息，若查询到消息，也即有存根则不消费消息，返回ACK至MQ broker，而若未查询到消息也即没有该消息的存根则消费该消息，并在消费成功之后返回ACK至MQ broker。此后，MQ broker即可将生产者本地存根中该消息的状态修改为已确认。其中，timer可以定时扫描生产者本地存根中是否存在未确认的消息，在有未确认的消息且发送次数未到限制（也即未达到预设次数）时，重新发送未确认状态的消息至MQbroker。

需要说明的是，上述实施例中生成端的步骤可以实现为生成端的微服务架构下的消息消费方法，消费端步骤可以实现成为消费端的微服务架构下的消息消费方法，在此不再赘述。

本申请实施例还提供了一种微服务架构下的消息消费装置，所述装置包括存储器和处理器，所述存储器中存储有至少一条程序指令，所述处理器通过加载并执行所述至少一条程序指令以实现以上所述的方法。

本申请实施例还提供了一种计算机存储介质，所述存储介质中存储有至少一条程序指令，所述至少一条程序指令被处理器加载并执行以实现以上所述的方法。

以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本发明的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。