[发明专利]消息队列的消息轨迹信息处理方法、系统、终端和存储介质

说明书

本发明提供了一种消息队列的消息轨迹信息处理方法、系统、终端和存储介质，所述方法包括：将消息队列的消息轨迹封装成轨迹信息并进行编码和序列化；将所述编码和序列化后的轨迹信息发送至消息队列进行缓存；将所述消息队列中缓存的轨迹信息进行反序列化和解码，并解析成存储模块能识别的对象；调用存储模块的应用程序接口并存储所述对象，以供查询。

技术领域

本申请涉及一种消息队列的消息轨迹信息处理方法、系统、终端和存储介质。

背景技术

消息队列是分布式系统中重要的组件，目前，使用较多的消息队列有RabbitMQ、Kafka、ZeroMQ、ActiveMQ等。现有基于消息队列的生产者和消费者的应用中，上游消息生产者发送消息并发送到消息队列，下游消息消费者从消费队列中消费消息进行数据处理。

但是现实应用中容易出现异常场景，例如上游生产者反馈发送了消息，但是下游消费者没有消费到，或者下游消费者对相同的消息消费了多次等等。这会导致消息队列传递和调用的不准确、不稳定。当这种异常场景出现时，上下游的消息记录就显得尤为必须和重要。

基于此，消息队列提供了轨迹插件(Tracing plugin)，在消息队列集群上通过命令就可以开启轨迹插件，将轨迹文件记录(tracer log)文件储存在消息队列集群磁盘上，后台通过页面配置后，可查询Exchange和Queue的消息轨迹。但是轨迹插件提供的功能过于简单，轨迹内容无法定制化，无法搜索，且Tracer log文件保存在集群磁盘上，对集群的稳定性会带来风险。如果集群的消息较多并且监控的轨迹较多，那么Tracer log文件会占用大量的磁盘，而且需要定期清理，给维护工作带来很大的挑战。Tracer log文件是纯文本，不方便进行历史消息的查询，其内容格式固定，缺乏关键信息，比如Message ID，RequestID等用户关注的信息，无法通过关键信息进行精确查找。

发明内容

下文呈现各种示例性技术方案的概述。在以下概述中可以进行一些简化和省略，其意在突出并介绍各种示例性技术方案的一些方面，但不限制本发明的范围。将在后续部分呈现足以允许本领域的普通技术人员产生并使用本发明概念的示例性技术方案的详细描述。

本发明的技术方案提供一种消息队列的消息轨迹信息处理方法、系统、终端和存储介质，可以提供大容量且稳定的轨迹信息的存储，并且实现轨迹信息内容的精确便捷地查找。

技术方案提供了一种消息队列的消息轨迹信息处理方法，包括：将消息队列的消息轨迹封装成轨迹信息并进行编码和序列化；将所述编码和序列化后的轨迹信息发送至消息队列进行缓存；将所述消息队列中缓存的轨迹信息进行反序列化和解码，并解析成存储模块能识别的对象；调用存储模块的应用程序接口并存储所述对象，以供查询。

在一个技术方案中，所述方法还包括通过以下至少之一的对象参数查询所述对象：资源类型、资源名称、消息ID、消息路由键、消息Tag、Request ID、Polaris trace ID、消息时间范围。

在一个技术方案中，所述消息队列的消息轨迹包括以下至少一种：消息发送时间、生产者IP、发送耗时、消费者IP、消息id、消息key、接收到消息的时间、开始消费时间、消费完成时间、消费结果状态、消费耗时。

在一个技术方案中，所述存储模块包括以下至少一种：Elasticsearch、HIVE、Mysql、DB。

在一个技术方案中，所述消息队列包括以下至少一种：ActiveMQ、RabbitMQ、ZeroMQ、Kafka。

在一个技术方案中，所述将消息队列的消息轨迹封装成轨迹信息包括将消息轨迹封装成以下至少之一：Java对象、C语言对象、C++对象、Python对象。

在一个技术方案中，所述编码是通过开发工具包进行编码。通过编码压缩数据，从而减少轨迹信息对业务端带宽的占用。