CN113064736A - 消息处理系统、方法、装置、电子设备和存储介质 - Google Patents
消息处理系统、方法、装置、电子设备和存储介质 Download PDFInfo
- Publication number
- CN113064736A CN113064736A CN202110296839.4A CN202110296839A CN113064736A CN 113064736 A CN113064736 A CN 113064736A CN 202110296839 A CN202110296839 A CN 202110296839A CN 113064736 A CN113064736 A CN 113064736A
- Authority
- CN
- China
- Prior art keywords
- message
- failure
- consumption
- node
- system node
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
本公开实施例公开了一种消息处理系统、方法、装置、电子设备和存储介质。该消息处理系统中：系统侧软件开发工具包，被配置成：响应于系统节点的消息处理结果指示消息发送失败或消息消费失败，将系统节点发送失败或消费失败的消息作为失败消息，从系统节点获取失败消息；向服务侧软件开发工具包发送失败消息；服务侧软件开发工具包，被配置成：将从系统侧软件开发工具包获得的失败消息写入守护服务；守护服务，被配置成：存储失败消息；通过超文本传输协议对失败消息进行重试。本公开实施例可以减小消息处理过程受损的情况发生，减少了业务系统对消息处理的投入，可以提升系统稳定性。
Description
技术领域
本公开涉及数据处理领域，尤其是一种消息处理系统、方法、装置、电子设备和存储介质。
背景技术
现有技术中，消息队列(MQ，Message Queue)已经逐渐成为分布式应用场景、内部通信的核心技术，其具有低耦合、可靠投递、广播、流量控制、最终一致性等特点。
通常，消息从生产到消费，中间需要经过消息队列。其中，从生产到消费的任意系统节点都可能会发生故障。现有的解决方案主要有以下两种：
第一种，基于日志补偿的解决方案。该方案在故障期间不会做额外处理，只是将发送失败的消息以日志形式存储好，当消息队列恢复时，再自动重新发送，通过分析之前存储的日志，将之前处理失败的消息重新发送给消息队列处理。
第二种，基于消息表定时对比与补偿的解决方案。该方案在生产端与消费端分别设计一张表，用来存储发送或消费的每一条消息，然后定时将生产端与消费端的消息表进行对比，对不一致的消息进行补偿。
可见，目前的解决方案在消息队列故障期间导致的消息消费失败、消息发送失败等情形下，无法对消息进行处理，业务受损时长、程度难以控制，故障排除后，消息每秒查询率(QPS，Queries-per-second)骤增，冲击系统稳定性。
发明内容
本公开实施例提供一种消息处理系统、方法、装置、电子设备和存储介质，可以在消息发送失败或消息消费失败的情况下，通过守护服务对失败消息进行重试，减小了消息处理过程受损的情况发生，减少了业务系统对消息处理的投入，可以提升系统稳定性。
根据本公开实施例的一个方面，提供的一种消息处理方法，包括：系统节点端和守护服务端，所述系统节点端包括系统节点和接入所述系统节点的系统侧软件开发工具包，所述守护服务端包括守护服务和供所述守护服务使用的服务侧软件开发工具包，其中：
所述系统侧软件开发工具包，被配置成：响应于所述系统节点的消息处理结果指示消息发送失败或消息消费失败，将所述系统节点发送失败或消费失败的消息作为失败消息，从所述系统节点获取所述失败消息；向所述服务侧软件开发工具包发送所述失败消息；
所述服务侧软件开发工具包，被配置成：将从所述系统侧软件开发工具包获得的所述失败消息写入所述守护服务；
所述守护服务，被配置成：存储所述失败消息；通过超文本传输协议对所述失败消息进行重试。
可选地，在本公开任一实施例的系统中，所述系统节点端包括消息生产节点端，所述消息生产节点端包括消息生产节点和接入所述消息生产节点的生产侧软件开发工具包；所述生产侧软件开发工具包，被配置成：针对所述消息生产节点每次发送消息的消息发送结果进行检测，确定所述消息发送结果是否指示消息发送失败；
和/或
所述系统节点端包括消息消费节点端，所述消息消费节点端包括消息消费节点和接入所述消息消费节点的消费侧软件开发工具包；所述消费侧软件开发工具包，被配置成：针对所述消息消费节点每次消费消息的消息消费结果进行检测，确定所述消息消费结果是否指示消息消费失败。
可选地，在本公开任一实施例的系统中，所述系统还包括消息数据库；以及
所述消息数据库，被配置成：响应于所述守护服务接收到消息处理结果，将所述消息处理结果进行存储，其中，所述消息处理结果包括消息消费结果和/或消息发送结果；
所述服务侧软件开发工具包，还被配置成：确定目标时间段内存储至所述预设消息数据库中的发送成功的消息、消费成功的消息、发送失败的消息和消费失败的消息是否相匹配；响应于确定不匹配，生成预警信息。
可选地，在本公开任一实施例的系统中，所述服务侧软件开发工具包，还被配置成：
输出所述预警信息；和/或
响应于确定不匹配，确定所述各个系统节点中出现故障的系统节点，以及所述出现故障的系统节点的故障类型。
根据本公开实施例的二个方面，提供的一种消息处理方法，包括：
响应于系统节点的消息处理结果指示消息发送失败或消息消费失败，将所述系统节点发送失败或消费失败的消息作为失败消息，从所述系统节点获取所述失败消息；
将所述失败消息存储至预设消息队列的队尾；
从所述预设消息队列中拉取位于队头的失败消息；
响应于所述系统节点为消息生产节点，将所拉取的失败消息发送至所述系统节点的下游系统节点进行消费。
可选地，在本公开任一实施例的方法中，所述方法还包括：
响应于所述系统节点为消息消费节点，将所拉取的失败消息发送至所述系统节点进行消费。
可选地，在本公开任一实施例的方法中，所述将所拉取的失败消息发送至所述系统节点的下游系统节点进行消费，包括：
将所拉取的失败消息打包；
通过超文本传输协议，将打包后的失败消息发送至所述系统节点的下游系统节点进行消费。
可选地，在本公开任一实施例的方法中，所述将所述失败消息存储至预设消息队列的队尾，包括：
将所获取的失败消息打包；
通过软件开发工具包中预先定义的应用程序接口，将打包后的失败消息发送给守护服务；
响应于所述守护服务接收到打包后的失败消息的报文，对所述守护服务接收到的、打包后的失败消息的报文进行拆包，将拆包后的失败消息存储至预设消息队列的队尾。
可选地，在本公开任一实施例的方法中，对失败消息的处理通过预先接入系统节点的系统侧软件开发工具包和/或供所述守护服务使用的软件开发工具包执行。
可选地，在本公开任一实施例的方法中，所述方法还包括：
响应于所述守护服务接收到消息处理结果的报文，将所述消息处理结果的报文存储至预设消息数据库，其中，所述消息处理结果包括消息发送成功、消息消费成功、消息发送失败和消息消费失败；
确定目标时间段内存储至所述预设消息数据库中的发送成功的消息、消费成功的消息、发送失败的消息和消费失败的消息是否相匹配；
响应于确定不匹配，生成预警信息。
可选地，在本公开任一实施例的方法中，所述方法还包括：
输出所述预警信息；和/或
响应于确定不匹配，确定所述各个系统节点中出现故障的系统节点，以及所述出现故障的系统节点的故障类型。
可选地，在本公开任一实施例的方法中，在所述从所述系统节点获取所述失败消息之前，所述方法还包括：
针对系统节点每次发送消息或消费消息的消息处理结果进行检测，确定所述处理结果是否指示消息发送失败或消息消费失败。
根据本公开实施例的第三个方面，提供的一种消息处理装置，包括：
获取单元，被配置成响应于系统节点的消息处理结果指示消息发送失败或消息消费失败，将所述系统节点发送失败或消费失败的消息作为失败消息，从所述系统节点获取所述失败消息；
第一存储单元，被配置成将所述失败消息存储至预设消息队列的队尾；
拉取单元，被配置成从所述预设消息队列中拉取位于队头的失败消息；
第一发送单元，被配置成响应于所述系统节点为消息生产节点，将所拉取的失败消息发送至所述系统节点的下游系统节点进行消费。
可选地，在本公开任一实施例的装置中，所述装置还包括：
第二发送单元，被配置成响应于所述系统节点为消息消费节点，将所拉取的失败消息发送至所述系统节点进行消费。
可选地，在本公开任一实施例的装置中，所述第一发送单元包括：
拉取子单元，被配置成将所拉取的失败消息打包；
第一发送子单元，被配置成通过超文本传输协议，将打包后的失败消息发送至所述系统节点的下游系统节点进行消费。
可选地，在本公开任一实施例的装置中，所述第一存储单元包括：
第一打包子单元，被配置成将所获取的失败消息打包；
第二发送子单元，被配置成通过软件开发工具包中预先定义的应用程序接口，将打包后的失败消息发送给守护服务；
存储子单元，被配置成响应于所述守护服务接收到打包后的失败消息的报文，对所述守护服务接收到的、打包后的失败消息的报文进行拆包，将拆包后的失败消息存储至预设消息队列的队尾。
可选地，在本公开任一实施例的装置中，对失败消息的处理通过预先接入系统节点的系统侧软件开发工具包和/或供所述守护服务使用的软件开发工具包执行。
可选地，在本公开任一实施例的装置中，所述装置还包括：
第二存储单元，被配置成响应于所述守护服务接收到消息处理结果的报文，将所述消息处理结果的报文存储至预设消息数据库，其中，所述消息处理结果包括消息发送成功、消息消费成功、消息发送失败和消息消费失败；
第一确定单元，被配置成确定目标时间段内存储至所述预设消息数据库中的发送成功的消息、消费成功的消息、发送失败的消息和消费失败的消息是否相匹配；
生成单元，被配置成响应于确定不匹配，生成预警信息。
可选地，在本公开任一实施例的装置中，所述装置还包括：
输出单元，被配置成输出所述预警信息；和/或
第二确定单元，被配置成响应于确定不匹配，确定所述各个系统节点中出现故障的系统节点，以及所述出现故障的系统节点的故障类型。
可选地，在本公开任一实施例的装置中，所述装置还包括：
检测单元，被配置成针对系统节点每次发送消息或消费消息的消息处理结果进行检测，确定所述处理结果是否指示消息发送失败或消息消费失败。
根据本公开实施例的第四个方面，提供的一种电子设备，包括：
存储器，用于存储计算机程序；
处理器，用于执行所述存储器中存储的计算机程序，且所述计算机程序被执行时，实现本公开上述任一实施例所述的方法。
根据本公开实施例的第五个方面，提供的一种计算机可读介质，该计算机程序被处理器执行时，实现如上述第一方面的消息处理方法中任一实施例的方法。
基于本公开上述实施例提供的消息处理系统、方法、装置、电子设备和存储介质中，消息处理系统包括系统节点端和守护服务端，系统节点端包括系统节点和接入系统节点的系统侧软件开发工具包，守护服务端包括守护服务和供守护服务使用的服务侧软件开发工具包，其中：系统侧软件开发工具包，被配置成：响应于系统节点的消息处理结果指示消息发送失败或消息消费失败，将系统节点发送失败或消费失败的消息作为失败消息，从系统节点获取失败消息；向服务侧软件开发工具包发送失败消息；服务侧软件开发工具包，被配置成：将从系统侧软件开发工具包获得的失败消息写入守护服务；守护服务，被配置成：存储失败消息；通过超文本传输协议对失败消息进行重试。本公开实施例可以在消息发送失败或消息消费失败的情况下，通过守护服务对失败消息进行重试，从而减小了消息处理过程受损的情况发生，减少了业务系统对消息处理的投入，减小了对系统造成的冲击，可以提升系统稳定性。
下面通过附图和实施例，对本公开的技术方案做进一步的详细描述。
附图说明
构成说明书的一部分的附图描述了本公开的实施例，并且连同描述一起用于解释本公开的原理。
参照附图，根据下面的详细描述，可以更加清楚地理解本公开，其中：
图1为本公开的消息处理系统的一个实施例的交互过程示意图。
图2为本公开的消息处理系统的一个实施例的应用场景示意图。
图3为针对图2的应用场景中的系统侧SDK的处理逻辑示意图。
图4为针对图2的应用场景中的守护服务的处理逻辑示意图。
图5为本公开的消息处理方法的第一个实施例的流程图。
图6为本公开的消息处理方法的第二个实施例的流程图。
图7为本公开消息处理装置一个实施例的结构示意图。
图8是本公开一示例性实施例提供的电子设备的结构图。
具体实施方式
现在将参照附图来详细描述本公开的各种示例性实施例。应注意到：除非另外具体说明，否则在这些实施例中阐述的部件和步骤的相对布置、数字表达式和数值不限制本公开的范围。
本领域技术人员可以理解，本公开实施例中的“第一”、“第二”等术语仅用于区别不同步骤、设备或模块等，既不代表任何特定技术含义，也不表示它们之间的必然逻辑顺序。
还应理解，在本公开实施例中，“多个”可以指两个或两个以上，“至少一个”可以指一个、两个或两个以上。
还应理解，对于本公开实施例中提及的任一部件、数据或结构，在没有明确限定或者在前后文给出相反启示的情况下，一般可以理解为一个或多个。
另外，本公开中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本公开中字符“/”，一般表示前后关联对象是一种“或”的关系。
还应理解，本公开对各个实施例的描述着重强调各个实施例之间的不同之处，其相同或相似之处可以相互参考，为了简洁，不再一一赘述。
同时，应当明白，为了便于描述，附图中所示出的各个部分的尺寸并不是按照实际的比例关系绘制的。
以下对至少一个示例性实施例的描述实际上仅仅是说明性的，决不作为对本公开及其应用或使用的任何限制。
对于相关领域普通技术人员已知的技术、方法和设备可能不作详细讨论，但在适当情况下，所述技术、方法和设备应当被视为说明书的一部分。
应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步讨论。
本公开实施例可以应用于终端设备、计算机系统和服务器中的至少一种电子设备，其可与众多其它通用或专用计算系统环境或配置一起操作。适于与终端设备、计算机系统和服务器中的至少一种电子设备一起使用的众所周知的计算系统、环境和/或配置的例子包括但不限于：个人计算机系统、服务器计算机系统、瘦客户机、厚客户机、手持或膝上设备、基于微处理器的系统、机顶盒、可编程消费电子产品、网络个人电脑、小型计算机系统﹑大型计算机系统和包括上述任何系统的分布式云计算技术环境，等等。
终端设备、计算机系统和服务器中的至少一种电子设备可以在由计算机系统执行的计算机系统可执行指令(诸如程序模块)的一般语境下描述。通常，程序模块可以包括例程、程序、目标程序、组件、逻辑、数据结构等等，它们执行特定的任务或者实现特定的抽象数据类型。计算机系统/服务器可以在分布式云计算环境中实施，分布式云计算环境中，任务是由通过通信网络链接的远程处理设备执行的。在分布式云计算环境中，程序模块可以位于包括存储设备的本地或远程计算系统存储介质上。
请参考图1，图1为本公开的消息处理系统的一个实施例的交互过程示意图。该消息处理系统包括系统节点端和守护服务端，系统节点端包括系统节点和接入系统节点的系统侧软件开发工具包，守护服务端包括守护服务和供守护服务使用的服务侧软件开发工具包，其中：系统侧软件开发工具包，被配置成：响应于系统节点的消息处理结果指示消息发送失败或消息消费失败，将系统节点发送失败或消费失败的消息作为失败消息，从系统节点获取失败消息；向服务侧软件开发工具包发送失败消息；服务侧软件开发工具包，被配置成：将从系统侧软件开发工具包获得的失败消息写入守护服务；守护服务，被配置成：存储失败消息；通过超文本传输协议对失败消息进行重试。
如图1所示，在101中，系统侧SDK(软件开发工具，Software Development Kit)从系统节点获取消息处理结果。
在本实施例中，系统侧SDK可以从系统节点获取消息处理结果。
可选的，针对消息消费节点每次处理消息(例如发送消息、消费消息)的消息处理结果进行检测，以确定该消息处理结果是否指示消息处理失败。此外，系统侧SDK也可以周期性地从系统节点获取消息处理结果。
在本实施例的一些可选的实现方式中，系统节点端包括消息生产节点端，消息生产节点端包括消息生产节点和接入消息生产节点的生产侧软件开发工具包。由此，生产侧软件开发工具包，被配置成：针对消息生产节点每次发送消息的消息发送结果进行检测，确定消息发送结果是否指示消息发送失败。或者，系统节点端包括消息消费节点端，消息消费节点端包括消息消费节点和接入消息消费节点的消费侧软件开发工具包。由此，消费侧软件开发工具包，被配置成：针对消息消费节点每次消费消息的消息消费结果进行检测，确定消息消费结果是否指示消息消费失败。
其中，在消息生产节点无法发送消息、发送消息次数超过预设次数等场景下，可以确定消息生发送失败；在消息消费节点消费消息超过预设次数等场景下，可以确定消息消费失败。
可以理解，上述可选的实现方式在发送消息或消费消息时，对发送消息或消费消息的消息处理结果进行强制检测，这样可以更为及时地发现故障，从而通过后续步骤，确保在故障期间仍然可以对失败消息进行重试。
在102中，系统侧SDK确定消息处理结果指示消息发送失败或消息消费失败。
在本实施例中，系统侧SDK可以确定消息处理结果是否指示消息发送失败或消息消费失败。这里以系统侧SDK确定消息处理结果指示消息发送失败或消息消费失败为例，对本实施例的技术方案进行说明。
在这里，系统节点可以是消息生产节点，也可以是消息消费节点。在该系统节点为消息生产节点的情况下，该系统节点可以发送消息、发送消息，若发送消息成功，则生成指示消息发送成功的消息处理结果，若发送消息失败，则生成指示消息发送失败的消息处理结果；在该系统节点为消息消费节点的情况下，该系统节点可以消费消息，若消费消息成功，则生成指示消息消费成功的消息处理结果，若消费消息失败，则生成指示消息消费失败的消息处理结果。
在103中，系统侧SDK从系统节点获取失败消息。
在本实施例中，系统侧SDK可以从系统节点获取失败消息。其中，失败消息为系统节点发送失败或消费失败的消息。
在104中，系统侧SDK向服务侧SDK发送失败消息。
在本实施例中，系统侧SDK可以向服务侧SDK发送103中获得的失败消息，或者按照先进先出的顺序，从存储有失败消息的队列中获得的失败消息。
在105中，服务侧SDK将从系统SDK获得的失败消息写入守护服务。
在106中，守护服务存储失败消息。
在本实施例中，服务侧SDK可以将从系统SDK获得的失败消息写入守护服务，之后，守护服务可以存储失败消息。其中，守护服务可以设置有用于存储失败消息的消息队列。在守护服务获得失败消息后，可以将该失败消息存储至消息队列的队尾。
在107中，守护服务通过超文本传输协议对失败消息进行重试。
在本实施例中，守护服务可以对失败消息进行HTTP(超文本传输协议，HypertextTransfer Protocol)重试。
作为示例，在系统节点为消息生产节点的情况下，可以将所拉取的失败消息发送至系统节点的下游系统节点进行消费；在系统节点为消息消费节点的情况下，可以将所拉取的失败消息发送至系统节点进行消费。
在本实施例的一些可选的实现方式中，该系统还包括消息数据库。其中，消息数据库，被配置成：响应于守护服务接收到消息处理结果，将消息处理结果进行存储，其中，消息处理结果包括消息消费结果和/或消息发送结果。在此基础上，服务侧软件开发工具包，还被配置成：确定目标时间段内存储至预设消息数据库中的发送成功的消息、消费成功的消息、发送失败的消息和消费失败的消息是否相匹配，以及在确定不匹配的情况下，生成预警信息。
其中，上述目标时间段可以是预先确定的时间段，也可以是按照预设时间间隔确定的时间段，例如，目标时间段可以为自预设时刻(例如系统节点发生故障时)开始，每间隔第一预设时长(例如0或1分钟等)，时长为第二预设时长(例如1分钟)的时间段。上述预警信息可以以文字、图像、语音中的至少一种方式输出。
作为示例，若目标时间段内各个系统节点生产的消息和消费的消息的数量相等，或者生产的消息和消费的消息的数量之差小于或等于预设数值，可以确定生产的消息和消费的消息相匹配；若目标时间段内各个系统节点生产的消息和消费的消息的数量不相等，或者生产的消息和消费的消息的数量之差大于预设数值，可以确定生产的消息和消费的消息不匹配。
这里，可以采用多种方式，确定目标时间段内存储至预设消息数据库中的发送成功的消息、消费成功的消息、发送失败的消息和消费失败的消息是否相匹配，此处不做具体限定。
可以理解，上述可选的实现方式可以通过生成预警信息及时进行预警，从而更为及时地发现及解决消息生产节点、消息消费节点或者消息队列的故障。
在本实施例的一些可选的实现方式中，服务侧软件开发工具包，还被配置成以下至少一项：
第一项，输出比对结果和预警信息中的至少一者。其中，比对结果可以包括消息内容、发送或拉取时间、处理状态(例如消费成功、消费失败、发送成功或发送失败等)。
第二项，在确定不匹配的情况下，确定各个系统节点中出现故障的系统节点，以及出现故障的系统节点的故障类型。
其中，上述执行主体可以确定每个系统节点发送成功的消息、消费成功的消息、发送失败的消息和消费失败的消息是否相匹配，从而确定出发送成功的消息、消费成功的消息、发送失败的消息和消费失败的消息不匹配的一个或多个系统节点，进一步地，通过该系统节点的所处理的消息内容、消息处理时间、消息处理状态等信息，确定出该系统节点的故障类型。作为示例，系统节点的故障类型可以包括以下至少一项：发送次数超过预设阈值、无法发送消息等等。
可以理解，上述可选的实现方式可以通过输出比对结果和预警信息中的至少一者，有助于更为及时地发现故障，通过确定各个系统节点中出现故障的系统节点，以及出现故障的系统节点的故障类型，更为及时地定位故障系统节点，确定故障原因。
作为示例，请参考图2，图2是本公开的消息处理系统的一个实施例的应用场景示意图。需要说明的是，图2仅仅是本公开的消息处理系统的一个实施例的一个应用场景，并不构成对本公开的实施例的限定。
在图2中，系统节点可以是消息生产节点201或消息消费节点204。每个系统节点(包括消息生产节点201和消息消费节点204)预先接入有系统侧SDK组件。图3中，消息生产节点201接入有系统侧SDK202，消息消费节点304接入有系统侧SDK205。消息生产节点201所生产的消息通常存储于消息队列203中，供消息消费节点204消费。系统侧SDK组件负责采集系统节点每分钟内生产与消费的消息数量，以及系统节点发送或消费失败的失败消息，将失败消息打包后的完整报文以API(Application Programming Interface，应用程序接口)方式，转发给守护服务。
守护服务207一端设置有供守护服务使用的SDK206。守护服务207负责接受SDK202或SDK205发送的打包报文，之后进行拆析，将其存储至预设消息数据库208中。分析系统节点间生产与消费消息是否匹配并呈现，对发送失败或消费失败的消息通过HTTP方式重新推送给业务系统节点处理，并接受业务系统节点返回的处理结果。
接下来请参考图3和图4。其中，图3为针对图2的应用场景中的SDK的处理逻辑示意图。
在图3中，系统侧SDK可以对现有主流MQ消息中间件Kafka、RabbitMQ、RocketMQ进行增强并提供对应增强版本SDK。在系统节点发送或消费消息后，系统侧SDK可以强制检测消息处理结果。如果消息处理结果指示消息消费失败或消息发送失败，则将失败消息以API方式写入守护服务。
图示中，在消息队列故障、发送或消费故障时，系统侧SDK能够获取到处理结果(包含自动检测消息队列是否故障的处理结果以及消息发送、消费是否成功的消息处理结果)，之后将失败消息打包，并通过系统侧SDK提供的API发送给守护服务。守护服务接收到打包消息后，通过供守护服务使用的SDK对消息拆包，之后分析、存储、重试。
此外，系统侧SDK还可以确定消息处理结果是否指示消息被成功处理，并对处理结果进行统计，该统计结果可以存储于预设消息数据库中，系统侧SDK可以定时(例如每分钟)向守护服务发送上述统计结果。在消息处理结果指示消息消费失败或消息发送失败的情况下，可以通过系统侧SDK打包失败消息，将打包后的失败消息发送至守护服务，通过供守护服务使用的SDK接收失败消息。
下面请参考图4。图4为针对图2的应用场景中的守护服务的处理逻辑示意图。
图4中，401，守护服务可以接收消息的报文。其中，该消息可以是任意消息，例如，发送成功的消息、发送失败的消息、消费成功的消息、消费失败的消息、统计结果或其他消息。
402，通过供守护服务使用的SDK验证报文头。
403，若报文格式错误，则执行丢弃操作。
404，若报文格式正确，则判断是否为失败消息的报文。
405，若是失败消息的报文，则通过供守护服务使用的SDK解包失败消息。
406，分析消息是否为系统节点生产或消费的消息。若不是系统节点生产或消费的消息则执行丢弃操作。
407，若是系统节点生产或消费的消息，则进一步判断是否为系统节点生产或消费的失败消息。
408，若不是系统节点生产或消费的失败消息，则将该消息写入预设消息数据库。
409，若是系统节点生产或消费的失败消息，则将该消息写入失败队列。
410，从消息队列拉取失败消息重试。
411，通过供守护服务使用的SDK打包失败消息。
412，通过系统侧SDK接收失败消息。
413，通过系统侧SDK处理失败消息。
414，通过系统侧SDK返回处理结果。
415，通过供守护服务使用的SDK读取处理结果，以及将该消息写入预设消息数据库。
416，若该消息的报文不是失败消息的报文，则进一步判断该消息是否为统计结果的报文。若不是统计结果的报文则执行丢弃操作。
417，若是统计结果的报文，则加工统计结果，例如将统计结果的格式调整为预设格式。
418，将该消息的报文写入预设消息数据库。
419，从预设数据库中拉取消息的报文。
420，对拉取的消息进行对比验证、问题预警。
可见，在消息到达守护服务后，可以通过供守护服务使用的SDK验证报文头。若报文格式错误则将该报文丢弃；若报文格式正确，则守护服务可以执行如下操作：若为失败消息的报文，则通过供守护服务使用的SDK解包失败消息并进行分析验证。验证通过的报文，分析报文是消息处理结果还是发送失败的消息或消费失败的消息，如果是消息处理结果报文则直接存储至预设消息数据库，如果是发送失败消息或消费失败消息的报文，则存储至预设消息数据库和失败队列。之后执行报文接受与验证操作，由供守护服务使用的SDK完成，再转发给报文分析层执行报文拆析等操作。然后执行报文拆析与存储，验证通过的报文，分析报文是消息处理结果还是发送失败的消息或消费失败的消息，如果是消息处理结果报文则直接存储至预设消息数据库，如果是发送失败消息或消费失败消息的报文，则存储至预设消息数据库和失败队列。最后执行统计与重试操作，统计是基于预设消息数据库中存储的消息处理结果，对每分钟内的发送成功的消息、消费成功的消息、发送失败的消息或消费失败的消息的数量进行比对验证与预警，重试是对失败队列的中的消息通过HTTP重试，并将重试结果同步到预设消息数据库。其中，重试结果可以包括重试次数等。
需要说明的是，除上面所记载的内容外，本申请实施例还可以包括与后续图3或图4对应的实施例相同或类似的特征、效果。在此不再赘述。
本公开的上述实施例提供的消息处理系统包括系统节点端和守护服务端，系统节点端包括系统节点和接入系统节点的系统侧软件开发工具包，守护服务端包括守护服务和供守护服务使用的服务侧软件开发工具包，其中：系统侧软件开发工具包，被配置成：响应于系统节点的消息处理结果指示消息发送失败或消息消费失败，将系统节点发送失败或消费失败的消息作为失败消息，从系统节点获取失败消息；向服务侧软件开发工具包发送失败消息；服务侧软件开发工具包，被配置成：将从系统侧软件开发工具包获得的失败消息写入守护服务；守护服务，被配置成：存储失败消息；通过超文本传输协议对失败消息进行重试。由此，可以在消息发送失败或消息消费失败的情况下，通过守护服务对失败消息进行重试，从而减小了消息处理过程受损的情况发生，减少了业务系统对消息处理的投入，减小了对系统造成的冲击，可以提升系统稳定性。
请参考图5，示出了根据本公开的消息处理方法的第一个实施例的流程500。该消息处理方法，包括：
501，响应于系统节点的消息处理结果指示消息发送失败或消息消费失败，将系统节点发送失败或消费失败的消息作为失败消息，从系统节点获取失败消息。
在本实施例中，在系统节点的消息处理结果指示消息发送失败或消息消费失败的情况下，可以将系统节点发送失败或消费失败的消息作为失败消息。从而消息处理方法的执行主体(例如服务器、终端设备、软件开发工具(SDK，Software Development Kit)等)可以通过有线连接方式或者无线连接方式从其他电子设备或者本地，从上述消息发送失败或消息消费失败的系统节点获取失败消息。
其中，现有主流MQ消息中间件包括Kafka、RabbitMQ、RocketMQ等。这里以RocketMQ为例，对消息的消费过程进行说明：
在RocketMQ并发消费时，会根据最大批消费数量，将拉取到的消费拆分到多个消费任务，提交到线程池中并发消费。提交到消息消费服务的消息，最终都会封装成一个个任务提交到线程池，通过实现相应接口，可以开启一个独立的线程，消息消费的过程通过执行特定方法来实现。根据源码可以得出，消息消费分为以下几个步骤：校验当前消息队列是否已被移除，避免重复消费；执行消息消费前置钩子函数；执行用户注册的实际消息消费过程；对消息消费返回结果进行处理以及消息消费是否超时判断；执行消息消费后置钩子函数；执行消息消费结果处理程序，包括消息重试，offset提交等；消费结果处理及提交。
在这里，系统节点可以是消息生产节点，也可以是消息消费节点。在该系统节点为消息生产节点的情况下，该系统节点可以发送消息、发送消息，若发送消息成功，则生成指示消息发送成功的消息处理结果，若发送消息失败，则生成指示消息发送失败的消息处理结果；在该系统节点为消息消费节点的情况下，该系统节点可以消费消息，若消费消息成功，则生成指示消息消费成功的消息处理结果，若消费消息失败，则生成指示消息消费失败的消息处理结果。
通常，在分布式服务中，在消息生产节点发送消息之后，可以将所生产的消息发送至预先确定的消息队列，以供消息消费节点从该消息队列中拉取消息按顺序进行消费。
在本实施例的一些可选的实现方式中，每个系统节点可以预先接入软件开发工具包，即系统侧(或业务侧)软件开发工具包，由此，上述执行主体可以通过预先接入该系统节点的系统侧(或业务侧)软件开发工具包，从系统节点获取失败消息。
可以理解，上述可选的实现方式通过为系统节点接入软件开发工具包，可以实现为特定的软件包、应用软件、软件框架、硬件平台、操作系统等产品提供服务，进而可以用以实现从系统节点获取失败消息的功能。
可选的，还可以通过在上述执行主体中安装预先开发的应用，或者执行预先存储的程序，来实现从系统节点获取失败消息的功能。
在本实施例的一些可选的实现方式中，在执行上述101之前，上述执行主体可以针对系统节点每次发送消息或消费消息的消息处理结果进行检测，从而确定处理结果是否指示消息发送失败或消息消费失败。
其中，在消息生产节点无法发送消息、发送消息次数超过预设次数等场景下，可以确定消息生发送失败；在消息消费节点消费消息超过预设次数等场景下，可以确定消息消费失败。
可以理解，上述可选的实现方式在发送消息或消费消息时，对发送消息或消费消息的消息处理结果进行强制检测，这样可以更为及时地发现故障，从而通过后续步骤，确保在故障期间仍然可以对失败消息进行重试。
在上述可选的实现方式的一些应用场景下，每个系统节点可以预先接入软件开发工具包，即系统侧(或业务侧)软件开发工具包，由此，上述执行主体可以通过预先接入该系统节点的系统侧(或业务侧)软件开发工具包，对系统节点每次发送消息或消费消息的消息处理结果进行检测，从而确定处理结果是否指示消息发送失败或消息消费失败。
可以理解，在上述应用场景中，通过为系统节点接入软件开发工具包，实现了对发送消息或消费消息的消息处理结果进行强制检测的功能。
可选的，还可以通过在上述执行主体中安装预先开发的应用，或者执行预先存储的程序，实现对发送消息或消费消息的消息处理结果进行强制检测的功能。
502，将失败消息存储至预设消息队列的队尾。
在本实施例中，上述执行主体可以将失败消息存储至预设消息队列的队尾。其中，预设消息队列可以用于存储失败消息。
在本实施例的一些可选的实现方式中，上述执行主体可以通过软件开发工具包，将失败消息存储至预设消息队列的队尾。其中，可以通过守护服务来守护上述预设消息队列的消费进程。上述软件开发工具包可以为系统侧软件开发工具包和/或供守护服务使用的软件开发工具包。
这里，守护服务可以监控上述预设消息队列，并将预设消息队列中的任务通过超文本传输协议(HyperText Transfer Protocol,HTTP)推送给对应系统节点进行重新处理。其中，HTTP的发送与接收报文可以在SDK中定义，由消息生产节点或消息消费节点引入SDK。
可以理解，上述可选的实现方式可以通过为系统节点接入软件开发工具包，实现将失败消息存储至预设消息队列的队尾的功能。
可选的，还可以通过在上述执行主体中安装预先开发的应用，或者执行预先存储的程序，来实现将失败消息存储至预设消息队列的队尾的功能。
在本实施例的一些可选的实现方式中，上述执行主体可以通过如下方式执行上述502:
步骤一，将所获取的失败消息打包。
这里，上述执行主体可以按照预先确定的协议，将所获取的失败消息打包。
此外，上述执行主体可以通过系统侧软件开发工具包，将所获取的失败消息打包。其中，系统侧软件开发工具包中，可以对打包协议进行定义。可选的，还可以通过在上述执行主体中安装预先开发的应用，或者执行预先存储的程序，将所获取的失败消息打包。
步骤二，通过软件开发工具包中预先定义的应用程序接口(API，ApplicationProgramming Interface)，将打包后的失败消息发送给守护服务。其中，上述软件开发工具包可以是系统侧软件开发工具包。
这里，守护服务可以监控上述预设消息队列，并将预设消息队列中的任务通过超文本传输协议推送给对应系统节点进行重新处理。其中，HTTP的发送与接收报文可以在SDK中定义，由消息生产节点或消息消费节点引入SDK。
步骤三，在守护服务接收到打包后的失败消息的报文的情况下，通过软件开发工具包对守护服务接收到的、打包后的失败消息的报文进行拆包，将拆包后的失败消息存储至预设消息队列的队尾。
可以理解，上述可选的实现方式中，在消息到达守护服务后，守护服务可以对消息进行分析，并将结果进行存储。
503，从预设消息队列中拉取位于队头的失败消息。
在本实施例中，上述执行主体可以从预设消息队列中拉取位于队头的失败消息。
在本实施例的一些可选的实现方式中，上述执行主体可以通过软件开发工具包，从预设消息队列中拉取位于队头的失败消息。其中，可以通过守护服务来守护上述从预设消息队列中拉取位于队头的失败消息的进程。上述软件开发工具包可以为系统侧软件开发工具包和/或供守护服务使用的软件开发工具包。
可以理解，上述可选的实现方式可以通过为系统节点接入软件开发工具包，实现从预设消息队列中拉取位于队头的失败消息。
504，响应于系统节点为消息生产节点，将所拉取的失败消息发送至系统节点的下游系统节点进行消费。
在本实施例中，在上述消息发送失败或消息消费失败的系统节点为消息生产节点的情况下，上述执行主体可以将所拉取的失败消息发送至系统节点的下游系统节点进行消费。
在本实施例的一些可选的实现方式中，在上述消息发送失败或消息消费失败的系统节点为消息生产节点的情况下，上述执行主体可以通过软件开发工具包，将所拉取的失败消息发送至系统节点的下游系统节点进行消费。其中，可以通过守护服务来守护上述消费进程。上述软件开发工具包可以为系统侧软件开发工具包和/或供守护服务使用的软件开发工具包。
可以理解，上述可选的实现方式通过为系统节点接入软件开发工具包，实现了将所拉取的失败消息发送至系统节点的下游系统节点进行消费。
可选的，还可以通过在上述执行主体中安装预先开发的应用，或者执行预先存储的程序，将所拉取的失败消息发送至系统节点的下游系统节点进行消费。
本公开的上述实施例提供的消息处理方法，可以在系统节点的消息处理结果指示消息发送失败或消息消费失败的情况下，将系统节点发送失败或消费失败的消息作为失败消息，从系统节点获取失败消息，之后，将失败消息存储至预设消息队列的队尾，然后，从预设消息队列中拉取位于队头的失败消息，最后，若上述系统节点为消息生产节点，则将所拉取的失败消息发送至系统节点的下游系统节点进行消费。本公开实施例可以在消息发送失败或消息消费失败的情况下，确保消息可以继续处理，减小了消息处理过程受损的情况发生，减少了业务系统对消息处理的投入，减小了对系统造成的冲击，可以提升系统稳定性。
在本实施例的一些可选的实现方式中，在系统节点为消息消费节点的情况下，上述执行主体还可以将所拉取的失败消息发送至系统节点进行消费。
在上述可选的实施例的一些应用场景中，在系统节点为消息消费节点的情况下，上述执行主体可以通过软件开发工具包，将所拉取的失败消息发送至系统节点进行消费。其中，可以通过守护服务来守护上述消费进程。上述软件开发工具包可以为系统侧软件开发工具包和/或供守护服务使用的软件开发工具包。
可以理解，上述可选的实现方式通过为系统节点接入软件开发工具包，实现了将所拉取的失败消息发送至系统节点进行消费。
可选的，还可以通过在上述执行主体中安装预先开发的应用，或者执行预先存储的程序，将所拉取的失败消息发送至系统节点行消费。
在本实施例的一些可选的实现方式中，上述执行主体可以执行如下步骤：
首先，在守护服务接收到消息处理结果的报文的情况下，将消息处理结果的报文存储至预设消息数据库。其中，上述消息处理结果包括消息发送成功、消息消费成功、消息发送失败和消息消费失败的处理结果。
之后，确定目标时间段内存储至预设消息数据库中的发送成功的消息、消费成功的消息、发送失败的消息和消费失败的消息是否相匹配。
其中，上述目标时间段可以是预先确定的时间段，也可以是按照预设时间间隔确定的时间段，例如，目标时间段可以为自预设时刻(例如系统节点发生故障时)开始，每间隔第一预设时长(例如0或1分钟等)，时长为第二预设时长(例如1分钟)的时间段。
作为示例，若目标时间段内各个系统节点生产的消息和消费的消息的数量相等，或者生产的消息和消费的消息的数量之差小于或等于预设数值，可以确定生产的消息和消费的消息相匹配；若目标时间段内各个系统节点生产的消息和消费的消息的数量不相等，或者生产的消息和消费的消息的数量之差大于预设数值，可以确定生产的消息和消费的消息不匹配。
这里，可以采用多种方式，确定目标时间段内存储至预设消息数据库中的发送成功的消息、消费成功的消息、发送失败的消息和消费失败的消息是否相匹配，此处不做具体限定。
然后，在确定不匹配的情况下，生成预警信息。
其中，上述预警信息可以以文字、图像、语音中的至少一种方式输出。
可以理解，上述可选的实现方式可以通过生成预警信息及时进行预警，从而更为及时地发现及解决消息生产节点、消息消费节点或者消息队列的故障。
在本实施例的一些可选的实现方式中，上述执行主体还可以执行以下至少一项：
第一项，输出比对结果和预警信息中的至少一者。其中，比对结果可以包括消息内容、发送或拉取时间、处理状态(例如消费成功、消费失败、发送成功或发送失败等)。
第二项，在确定不匹配的情况下，确定各个系统节点中出现故障的系统节点，以及出现故障的系统节点的故障类型。
其中，上述执行主体可以确定每个系统节点发送成功的消息、消费成功的消息、发送失败的消息和消费失败的消息是否相匹配，从而确定出发送成功的消息、消费成功的消息、发送失败的消息和消费失败的消息不匹配的一个或多个系统节点，进一步地，通过该系统节点的所处理的消息内容、消息处理时间、消息处理状态等信息，确定出该系统节点的故障类型。作为示例，系统节点的故障类型可以包括以下至少一项：发送次数超过预设阈值、无法发送消息等等。
可以理解，上述可选的实现方式可以通过输出比对结果和预警信息中的至少一者，有助于更为及时地发现故障，通过确定各个系统节点中出现故障的系统节点，以及出现故障的系统节点的故障类型，更为及时地定位故障系统节点，确定故障原因。
进一步参考图6，图6是本公开的消息消费的第二个实施例的流程图。该消息消费流程600，包括：
601，响应于系统节点的消息处理结果指示消息发送失败或消息消费失败，将系统节点发送失败或消费失败的消息作为失败消息，从系统节点获取失败消息。
在本实施例中，在系统节点的消息处理结果指示消息发送失败或消息消费失败的情况下，消息处理方法的执行主体(例如服务器、终端设备、具有图像处理功能的图像处理单元等)可以将系统节点发送失败或消费失败的消息作为失败消息，从系统节点获取失败消息。
在本实施例中，601与图5对应实施例中的501基本一致，这里不再赘述。
602，将失败消息存储至预设消息队列的队尾。
在本实施例中，上述执行主体可以将失败消息存储至预设消息队列的队尾。
在本实施例中，602与图5对应实施例中的502基本一致，这里不再赘述。
603，从预设消息队列中拉取位于队头的失败消息。
在本实施例中，上述执行主体可以从预设消息队列中拉取位于队头的失败消息。
在本实施例中，步骤603与图5对应实施例中的步骤503基本一致，这里不再赘述。
604，响应于系统节点为消息生产节点，将所拉取的失败消息打包。
在本实施例中，在系统节点为消息生产节点的情况下，上述执行主体可以将所拉取的失败消息打包。
其中，上述执行主体可以按照预先确定的协议，将所拉取的失败消息打包。
此外，上述执行主体可以通过软件开发工具包，将所拉取的失败消息打包。其中，可以通过守护服务来守护上述打包进程。上述软件开发工具包可以为供守护服务使用的软件开发工具包。
其中，软件开发工具包中，可以对打包协议进行定义。可选的，还可以通过在上述执行主体中安装预先开发的应用，或者执行预先存储的程序，将所拉取的失败消息打包。
605，通过超文本传输协议，将打包后的失败消息发送至系统节点的下游系统节点进行消费。
在本实施例中，上述执行主体可以通过超文本传输协议，将打包后的失败消息发送至系统节点的下游系统节点进行消费。
在这里，上述执行主体可以基于软件开发工具包、预先开发的应用，或者执行预先存储的程序，通过超文本传输协议，将打包后的失败消息发送至系统节点的下游系统节点进行消费。其中，上述软件开发工具包可以为供守护服务使用的软件开发工具包。
需要说明的是，除上面所记载的内容外，本申请实施例还可以包括与图5对应的实施例相同或类似的特征、效果，在此不再赘述。
下面返回图6。从图6中可以看出，本实施例中的消息处理方法的流程600可以通过超文本传输协议，将打包后的失败消息发送至系统节点的下游系统节点，由此可以使失败消息发送至系统节点的下游系统节点的过程更为简单、快速、灵活，从而进一步提升系统稳定性。
进一步参考图7，作为对上述各图所示方法的实现，本公开提供了一种消息处理装置的一个实施例，该装置实施例与图5或图6所示的方法实施例相对应，除下面所记载的特征外，该装置实施例还可以包括与图1所示的方法实施例相同或相应的特征，以及产生与图5或图6所示的方法实施例相同或相应的效果。该装置具体可以应用于各种电子设备中。
如图7所示，本实施例的消息处理装置700包括：获取单元701，被配置成响应于系统节点的消息处理结果指示消息发送失败或消息消费失败，将系统节点发送失败或消费失败的消息作为失败消息，从系统节点获取失败消息；第一存储单元702，被配置成将失败消息存储至预设消息队列的队尾；拉取单元703，被配置成从预设消息队列中拉取位于队头的失败消息；第一发送单元704，被配置成响应于系统节点为消息生产节点，将所拉取的失败消息发送至系统节点的下游系统节点进行消费。
在本实施例中，消息处理装置700的获取单元701可以在系统节点的消息处理结果指示消息发送失败或消息消费失败的情况下，将系统节点发送失败或消费失败的消息作为失败消息，从系统节点获取失败消息。
在本实施例中，第一存储单元702可以将失败消息存储至预设消息队列的队尾。
在本实施例中，拉取单元703可以从预设消息队列中拉取位于队头的失败消息。
在本实施例中，在系统节点为消息生产节点的情况下，第一发送单元704可以将所拉取的失败消息发送至系统节点的下游系统节点进行消费。
在本实施例的一些可选的实现方式中，该装置700还包括：
第二发送单元(图中未示出)，被配置成响应于系统节点为消息消费节点，将所拉取的失败消息发送至系统节点进行消费。
在本实施例的一些可选的实现方式中，第一发送单元704包括：
拉取子单元(图中未示出)，被配置成将所拉取的失败消息打包；
第一发送子单元(图中未示出)，被配置成通过超文本传输协议，将打包后的失败消息发送至系统节点的下游系统节点进行消费。
在本实施例的一些可选的实现方式中，第一存储单元702包括：
第一打包子单元(图中未示出)，被配置成将所获取的失败消息打包；
第二发送子单元(图中未示出)，被配置成通过软件开发工具包中预先定义的应用程序接口，将打包后的失败消息发送给守护服务；
存储子单元(图中未示出)，被配置成响应于守护服务接收到打包后的失败消息的报文，通过软件开发工具包对守护服务接收到的、打包后的失败消息的报文进行拆包，将拆包后的失败消息存储至预设消息队列的队尾。
在本实施例的一些可选的实现方式中，对失败消息的处理通过预先接入系统节点的系统侧软件开发工具包和/或供守护服务使用的软件开发工具包执行。
在本实施例的一些可选的实现方式中，该装置700还包括：
第二存储单元(图中未示出)，被配置成响应于守护服务接收到消息处理结果的报文，将消息处理结果的报文存储至预设消息数据库，其中，消息处理结果包括消息发送成功、消息消费成功、消息发送失败和消息消费失败；
第一确定单元(图中未示出)，被配置成确定目标时间段内存储至所述预设消息数据库中的发送成功的消息、消费成功的消息、发送失败的消息和消费失败的消息是否相匹配；
生成单元(图中未示出)，被配置成响应于确定不匹配，生成预警信息。
在本实施例的一些可选的实现方式中，该装置700还包括：
输出单元(图中未示出)，被配置成输出比对结果和预警信息中的至少一者；和/或
第二确定单元(图中未示出)，被配置成响应于确定不匹配，确定各个系统节点中出现故障的系统节点，以及出现故障的系统节点的故障类型。
在本实施例的一些可选的实现方式中，该装置700还包括：
检测单元(图中未示出)，被配置成针对系统节点每次发送消息或消费消息的消息处理结果进行检测，确定处理结果是否指示消息发送失败或消息消费失败。
本公开的上述实施例提供的消息处理装置中，获取单元701可以，在系统节点的消息处理结果指示消息发送失败或消息消费失败的情况下，将系统节点发送失败或消费失败的消息作为失败消息，从系统节点获取失败消息，之后，第一存储单元702可以将失败消息存储至预设消息队列的队尾，然后，拉取单元703可以从预设消息队列中拉取位于队头的失败消息，最后，第一发送单元704可以在系统节点为消息生产节点的情况下，将所拉取的失败消息发送至系统节点的下游系统节点进行消费。本公开实施例可以在消息发送失败或消息消费失败的情况下，确保消息可以继续处理，减小了消息处理过程受损的情况发生，减少了业务系统对消息处理的投入，减小了对系统造成的冲击，可以提升系统稳定性。
下面，参考图8来描述根据本公开实施例的电子设备。该电子设备可以是第一设备和第二设备中的任一个或两者、或与它们独立的单机设备，该单机设备可以与第一设备和第二设备进行通信，以从它们接收所采集到的输入信号。
图8图示了根据本公开实施例的电子设备的框图。
如图8所示，电子设备8包括一个或多个处理器801和存储器802。
处理器801可以是中央处理单元(CPU)或者具有数据处理能力和/或指令执行能力的其他形式的处理单元，并且可以控制电子设备中的其他组件以执行期望的功能。
存储器802可以包括一个或多个计算机程序产品，所述计算机程序产品可以包括各种形式的计算机可读存储介质，例如易失性存储器和/或非易失性存储器。所述易失性存储器例如可以包括随机存取存储器(RAM)和/或高速缓冲存储器(cache)等。所述非易失性存储器例如可以包括只读存储器(ROM)、硬盘、闪存等。在所述计算机可读存储介质上可以存储一个或多个计算机程序指令，处理器801可以运行所述程序指令，以实现上文所述的本公开的各个实施例的消息处理方法以及/或者其他期望的功能。在所述计算机可读存储介质中还可以存储诸如输入信号、信号分量、噪声分量等各种内容。
在一个示例中，电子设备还可以包括：输入装置803和输出装置804，这些组件通过总线系统和/或其他形式的连接机构(未示出)互连。
例如，在该电子设备是第一设备或第二设备时，该输入装置803可以是上述的麦克风或麦克风阵列，用于捕捉声源的输入信号。在该电子设备是单机设备时，该输入装置803可以是通信网络连接器，用于从第一设备和第二设备接收所采集的输入信号。
此外，该输入装置803还可以包括例如键盘、鼠标等等。该输出装置804可以向外部输出各种信息，包括确定出的距离信息、方向信息等。该输出装置804可以包括例如显示器、扬声器、打印机、以及通信网络及其所连接的远程输出设备等等。
当然，为了简化，图8中仅示出了该电子设备中与本公开有关的组件中的一些，省略了诸如总线、输入/输出接口等等的组件。除此之外，根据具体应用情况，电子设备还可以包括任何其他适当的组件。
除了上述方法和设备以外，本公开的实施例还可以是计算机程序产品，其包括计算机程序指令，所述计算机程序指令在被处理器运行时使得所述处理器执行本说明书上述“示例性方法”部分中描述的根据本公开各种实施例的消息处理方法中的步骤。
所述计算机程序产品可以以一种或多种程序设计语言的任意组合来编写用于执行本公开实施例操作的程序代码，所述程序设计语言包括面向对象的程序设计语言，诸如Java、C++等，还包括常规的过程式程序设计语言，诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。
此外，本公开的实施例还可以是计算机可读存储介质，其上存储有计算机程序指令，所述计算机程序指令在被处理器运行时使得所述处理器执行本说明书上述“示例性方法”部分中描述的根据本公开各种实施例的消息处理方法中的步骤。
所述计算机可读存储介质可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以包括但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。
以上结合具体实施例描述了本公开的基本原理，但是，需要指出的是，在本公开中提及的优点、优势、效果等仅是示例而非限制，不能认为这些优点、优势、效果等是本公开的各个实施例必须具备的。另外，上述公开的具体细节仅是为了示例的作用和便于理解的作用，而非限制，上述细节并不限制本公开为必须采用上述具体的细节来实现。
本说明书中各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似的部分相互参见即可。对于系统实施例而言，由于其与方法实施例基本对应，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
本说明书中各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似的部分相互参见即可。对于系统实施例而言，由于其与方法实施例基本对应，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
可能以许多方式来实现本公开的方法和装置。例如，可通过软件、硬件、固件或者软件、硬件、固件的任何组合来实现本公开的方法和装置。用于所述方法的步骤的上述顺序仅是为了进行说明，本公开的方法的步骤不限于以上具体描述的顺序，除非以其它方式特别说明。此外，在一些实施例中，还可将本公开实施为记录在记录介质中的程序，这些程序包括用于实现根据本公开的方法的机器可读指令。因而，本公开还覆盖存储用于执行根据本公开的方法的程序的记录介质。
本公开的描述是为了示例和描述起见而给出的，而并不是无遗漏的或者将本公开限于所公开的形式。很多修改和变化对于本领域的普通技术人员而言是显然的。选择和描述实施例是为了更好说明本公开的原理和实际应用，并且使本领域的普通技术人员能够理解本公开从而设计适于特定用途的带有各种修改的各种实施例。
Claims (10)
1.一种消息处理系统，其特征在于，所述消息处理系统包括系统节点端和守护服务端，所述系统节点端包括系统节点和接入所述系统节点的系统侧软件开发工具包，所述守护服务端包括守护服务和供所述守护服务使用的服务侧软件开发工具包，其中：
所述系统侧软件开发工具包，被配置成：响应于所述系统节点的消息处理结果指示消息发送失败或消息消费失败，将所述系统节点发送失败或消费失败的消息作为失败消息，从所述系统节点获取所述失败消息；向所述服务侧软件开发工具包发送所述失败消息；
所述服务侧软件开发工具包，被配置成：将从所述系统侧软件开发工具包获得的所述失败消息写入所述守护服务；
所述守护服务，被配置成：存储所述失败消息；通过超文本传输协议对所述失败消息进行重试。
2.根据权利要求1所述的系统，其特征在于，所述系统节点端包括消息生产节点端，所述消息生产节点端包括消息生产节点和接入所述消息生产节点的生产侧软件开发工具包；所述生产侧软件开发工具包，被配置成：针对所述消息生产节点每次发送消息的消息发送结果进行检测，确定所述消息发送结果是否指示消息发送失败；
和/或
所述系统节点端包括消息消费节点端，所述消息消费节点端包括消息消费节点和接入所述消息消费节点的消费侧软件开发工具包；所述消费侧软件开发工具包，被配置成：针对所述消息消费节点每次消费消息的消息消费结果进行检测，确定所述消息消费结果是否指示消息消费失败。
3.根据权利要求1或2所述的系统，其特征在于，所述系统还包括消息数据库；以及
所述消息数据库，被配置成：响应于所述守护服务接收到消息处理结果，将所述消息处理结果进行存储，其中，所述消息处理结果包括消息消费结果和/或消息发送结果；
所述服务侧软件开发工具包，还被配置成：确定目标时间段内存储至所述预设消息数据库中的发送成功的消息、消费成功的消息、发送失败的消息和消费失败的消息是否相匹配；响应于确定不匹配，生成预警信息。
4.根据权利要求3所述的系统，其特征在于，所述服务侧软件开发工具包，还被配置成：
输出所述预警信息；和/或
响应于确定不匹配，确定所述各个系统节点中出现故障的系统节点，以及所述出现故障的系统节点的故障类型。
5.一种消息处理方法，其特征在于，所述方法包括：
响应于系统节点的消息处理结果指示消息发送失败或消息消费失败，将所述系统节点发送失败或消费失败的消息作为失败消息，从所述系统节点获取所述失败消息；
将所述失败消息存储至预设消息队列的队尾；
从所述预设消息队列中拉取位于队头的失败消息；
响应于所述系统节点为消息生产节点，将所拉取的失败消息发送至所述系统节点的下游系统节点进行消费。
6.根据权利要求5所述的方法，其特征在于，所述将所述失败消息存储至预设消息队列的队尾，包括：
将所获取的失败消息打包；
通过软件开发工具包中预先定义的应用程序接口，将打包后的失败消息发送给守护服务；
响应于所述守护服务接收到打包后的失败消息的报文，对所述守护服务接收到的、打包后的失败消息的报文进行拆包，将拆包后的失败消息存储至预设消息队列的队尾。
7.根据权利要求6所述的方法，其特征在于，所述方法还包括：
响应于所述守护服务接收到消息处理结果的报文，将所述消息处理结果的报文存储至预设消息数据库，其中，所述消息处理结果包括消息发送成功、消息消费成功、消息发送失败和消息消费失败；
确定目标时间段内存储至所述预设消息数据库中的发送成功的消息、消费成功的消息、发送失败的消息和消费失败的消息是否相匹配；
响应于确定不匹配，生成预警信息。
8.一种消息处理装置，其特征在于，所述装置包括：
获取单元，被配置成响应于系统节点的消息处理结果指示消息发送失败或消息消费失败，将所述系统节点发送失败或消费失败的消息作为失败消息，从所述系统节点获取所述失败消息；
第一存储单元，被配置成将所述失败消息存储至预设消息队列的队尾；
拉取单元，被配置成从所述预设消息队列中拉取位于队头的失败消息；
第一发送单元，被配置成响应于所述系统节点为消息生产节点，将所拉取的失败消息发送至所述系统节点的下游系统节点进行消费。
9.一种电子设备，其特征在于，包括：
存储器，用于存储计算机程序；
处理器，用于执行所述存储器中存储的计算机程序，且所述计算机程序被执行时，实现上述权利要求5-7任一所述的方法。
10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时，实现上述权利要求5-7任一所述的方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110296839.4A CN113064736A (zh) | 2021-03-19 | 2021-03-19 | 消息处理系统、方法、装置、电子设备和存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110296839.4A CN113064736A (zh) | 2021-03-19 | 2021-03-19 | 消息处理系统、方法、装置、电子设备和存储介质 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113064736A true CN113064736A (zh) | 2021-07-02 |
Family
ID=76562453
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110296839.4A Pending CN113064736A (zh) | 2021-03-19 | 2021-03-19 | 消息处理系统、方法、装置、电子设备和存储介质 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113064736A (zh) |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20180375783A1 (en) * | 2017-06-27 | 2018-12-27 | Atlassian Pty Ltd | Retry handling in messaging queues |
| CN109743133A (zh) * | 2018-12-25 | 2019-05-10 | 中国联合网络通信集团有限公司 | 数据对账方法及装置 |
| CN110224922A (zh) * | 2019-05-21 | 2019-09-10 | 成都路行通信息技术有限公司 | 一种基于RabbitMQ的异步消息重试方法、系统及系统构建方法 |
| CN110740145A (zh) * | 2018-07-18 | 2020-01-31 | 北京京东尚科信息技术有限公司 | 消息消费方法、装置、存储介质及电子设备 |
| CN112328418A (zh) * | 2020-11-27 | 2021-02-05 | 行吟信息科技（上海）有限公司 | 一种提升mq同步可靠性的方法和系统 |
-
2021
- 2021-03-19 CN CN202110296839.4A patent/CN113064736A/zh active Pending
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20180375783A1 (en) * | 2017-06-27 | 2018-12-27 | Atlassian Pty Ltd | Retry handling in messaging queues |
| CN110740145A (zh) * | 2018-07-18 | 2020-01-31 | 北京京东尚科信息技术有限公司 | 消息消费方法、装置、存储介质及电子设备 |
| CN109743133A (zh) * | 2018-12-25 | 2019-05-10 | 中国联合网络通信集团有限公司 | 数据对账方法及装置 |
| CN110224922A (zh) * | 2019-05-21 | 2019-09-10 | 成都路行通信息技术有限公司 | 一种基于RabbitMQ的异步消息重试方法、系统及系统构建方法 |
| CN112328418A (zh) * | 2020-11-27 | 2021-02-05 | 行吟信息科技（上海）有限公司 | 一种提升mq同步可靠性的方法和系统 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108595304B (zh) | 网页监控方法及装置 | |
| KR100943012B1 (ko) | 멀티-라인 로그 엔트리의 머징 | |
| US8219685B2 (en) | Thin client apparatus, a control method thereof, and a program storage medium for a thin client system for intergrating input information items and transmitting the intergrated information to a server | |
| US10447796B2 (en) | Pushlet instant messaging framework and pushlet instant messaging method | |
| US20150067146A1 (en) | Custom correlation of a distributed business transaction | |
| CN110753050B (zh) | 协议文档的生成方法及装置、计算机存储介质、电子设备 | |
| US20150026293A1 (en) | Method, apparatus, terminal, and server for synchronizing terminal mirror | |
| CN113360301B (zh) | 一种消息传输系统及方法 | |
| CN111694797A (zh) | 一种文件上传及解析方法、装置、服务器及介质 | |
| US20230037390A1 (en) | Techniques to provide streaming data resiliency utilizing a distributed message queue system | |
| CN109218338B (zh) | 信息处理系统、方法和装置 | |
| CN112948551A (zh) | 日志获取方法、装置、计算机设备及存储介质 | |
| CN111049899B (zh) | kafka消息存储系统、方法、装置及计算机可读存储介质 | |
| CN113064736A (zh) | 消息处理系统、方法、装置、电子设备和存储介质 | |
| KR20120071175A (ko) | 웹 플랫폼이 탑재된 이동통신 단말기와 이를 이용한 로그 정보 제공 방법 및 웹 플랫폼에 대한 검증 시스템과 이를 이용한 검증 방법 | |
| CN109586979B (zh) | 一种报文传输方法及装置 | |
| US20120066305A1 (en) | Transmitting system and method thereof | |
| CN114553663B (zh) | 一种异常检测方法、装置、设备和存储介质 | |
| CN112860770B (zh) | 报表生成的方法、装置、电子设备和存储介质 | |
| JP5499484B2 (ja) | プログラム修正システム、端末装置、サーバ装置、プログラム修正方法、エラー検出プログラム及び管理プログラム | |
| CN114328152A (zh) | 日志记录方法、装置、设备及介质 | |
| CN110362464B (zh) | 软件分析方法及设备 | |
| CN113852835A (zh) | 直播音频处理方法、装置、电子设备以及存储介质 | |
| CN108920589B (zh) | 浏览劫持识别方法、装置、服务器及存储介质 | |
| US10079739B2 (en) | Computer-implemented method for handling log file |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| TA01 | Transfer of patent application right | ||
| TA01 | Transfer of patent application right |
Effective date of registration: 20210823 Address after: 100085 Floor 101 102-1, No. 35 Building, No. 2 Hospital, Xierqi West Road, Haidian District, Beijing Applicant after: Seashell Housing (Beijing) Technology Co.,Ltd. Address before: 101300 room 24, 62 Farm Road, Erjie village, Yangzhen Town, Shunyi District, Beijing Applicant before: Beijing fangjianghu Technology Co.,Ltd. |
|
| RJ01 | Rejection of invention patent application after publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20210702 |