一种消息处理的方法、装置及设备与流程

本发明属于数据业务技术领域，尤其涉及一种消息处理的方法、装置、设备和计算机存储介质。

背景技术：

传统模式的web系统以客户端发出请求、服务器端响应的方式工作。不能满足很多现实应用的需求，譬如：针对业务处理轨迹跟踪结果展示，需要在对业务处理轨迹分析的同时，查看业务轨迹分析的结果。一般服务器端调用数据分析聚合处理程序，在业务处理的过程中会将处理结果保存到数据库表中。然后由界面程序通过读取数据库表结果，将结果呈现到用户界面上。这种方式由于是客户端主动连接获取的数据结果，所以会产生一定程度的延时，并且也会增加服务器端的承载压力。

另外，在针对大并发(即数据量大于一定阈值且需要被同时处理)的业务处理轨迹的场景下，若通过上述数据库表查询过滤选出被关注的任意一个业务处理轨迹(即业务数据的生命周期)，由于数据量大，查询过程耗时会很长，降低用户体验感。

技术实现要素：

本申请实施例提供一种消息处理的方法、装置、设备和计算机存储介质，通过轨迹日志携带业务轨迹标识，并记录业务指令的生命周期，可以通过业务轨迹标识精确定位展示跟踪业务处理轨迹。另外，根据服务端主动向订阅业务轨迹标识的用户端推送待推送消息，缩短了处理速度，提升用户体验感。

第一方面，本申请实施例提供了一种消息处理的方法，该方法可以包括：接收业务指令，根据业务指令生成对应的业务轨迹日志，业务轨迹日志用于记录业务指令的生命周期；

解析轨迹日志，确定轨迹日志中的业务轨迹标识；

判断业务轨迹标识是否存在于预设订阅业务标识库中；

在存在的情况下，将业务轨迹标识对应的轨迹日志转换为待推送消息，以便于基于cometd服务将待推送消息向订阅业务轨迹标识的用户端推送。

本申请，无需进行一边存储一边显示，实现了消息不落地直接送达订阅的客户端，缩短了从数据生成到数据展现的时间间隔；根据业务轨迹标识精确定位，根据轨迹日志展示跟踪业务处理轨迹，提高了处理速度，减少人工等待，达到实时跟踪、多客户端界面同时跟踪的效果。此外，该方法可以支持多个订阅的客户端同时监控同一笔的业务轨迹，以提升用户体验感。

在一种可能的实施方式中，上述在“解析轨迹日志，确定轨迹日志中的业务轨迹标识”的步骤中，可以具体包括：

按照预设轨迹日志解析规则解析轨迹日志，确定轨迹日志中的业务轨迹标识。

在另一种可能的实施方式中，在上述“解析轨迹日志，确定轨迹日志中的业务轨迹标识”的步骤之前，还可以包括：

将业务轨迹日志的状态从待处理状态修改为已处理状态。

在又一种可能的实施方式中，在上述“解析轨迹日志，确定轨迹日志中的业务轨迹标识”的步骤中，具体可以包括：

在业务轨迹日志的状态为已处理状态的情况下，解析轨迹日志，确定轨迹日志中的业务轨迹标识。

在再一种可能的实施方式中，在上述“解析轨迹日志，确定轨迹日志中的业务轨迹标识”的步骤之前，还可以包括：

按照时间顺序在业务指令的列表中缓存业务轨迹日志。

在再一种可能的实施方式中，在上述“解析轨迹日志，确定轨迹日志中的业务轨迹标识”的步骤中，具体可以包括：

按照时间顺序解析业务指令的列表中缓存的业务轨迹日志，确定轨迹日志中的业务轨迹标识。

在再一种可能的实施方式中，在上述“判断业务轨迹标识是否存在于预设订阅业务标识库中”的步骤中，可以包括：调用cometd服务，根据cometd服务判断业务轨迹标识是否存在于预设订阅业务标识库中。

在再一种可能的实施方式中，在上述“在存在的情况下，将业务轨迹标识对应的轨迹日志转换为待推送消息”的步骤中，具体可以包括：

根据cometd服务将业务轨迹标识对应的轨迹日志转换为待推送消息。

在再一种可能的实施方式中，上述方法还可以包括：在不存在的情况下，放弃与业务轨迹标识对应的轨迹日志。

在再一种可能的实施方式中，其中“预设订阅业务标识库”可以基于以下步骤确定：通过用户端接收用户创建的预设订阅业务标识库，预设订阅业务标识库包括至少一个预设订阅业务标识。

第二方面，本申请实施例提供了一种消息处理的装置，该装置可以包括：

收发模块，用于接收业务指令，根据业务指令生成对应的业务轨迹日志，业务轨迹日志用于记录业务指令的生命周期；

解析模块，用于解析轨迹日志，确定轨迹日志中的业务轨迹标识；

判断模块，用于判断业务轨迹标识是否存在于预设订阅业务标识库中；

处理模块，用于在存在的情况下，将业务轨迹标识对应的轨迹日志转换为待推送消息，以便于处理模块调用收发模块，基于cometd服务将待推送消息向订阅业务轨迹标识的用户端推送。

本申请，无需进行一边存储一边显示，实现了消息不落地直接送达订阅的客户端，缩短了从数据生成到数据展现的时间间隔；根据业务轨迹标识精确定位，根据轨迹日志展示跟踪业务处理轨迹，提高了处理速度，减少人工等待，达到实时跟踪、多客户端界面同时跟踪的效果。此外，该方法可以支持多个订阅的客户端同时监控同一笔的业务轨迹，以提升用户体验感。在一种可能的实施方式中，上述“解析模块”具体可以用于，按照预设轨迹日志解析规则解析轨迹日志，确定轨迹日志中的业务轨迹标识。

在另一种可能的实施方式中，上述“处理模块”还用于，将业务轨迹日志的状态从待处理状态修改为已处理状态。

在又一种可能的实施方式中，上述“解析模块”具体可以用于，在业务轨迹日志的状态为已处理状态的情况下，解析轨迹日志，确定轨迹日志中的业务轨迹标识。

在再一种可能的实施方式中，该装置还包括：缓存模块，用于按照时间顺序在业务指令的列表中缓存业务轨迹日志。

在再一种可能的实施方式中，上述“解析模块”具体可以用于，按照时间顺序解析业务指令的列表中缓存的业务轨迹日志，确定轨迹日志中的业务轨迹标识。

在再一种可能的实施方式中，上述“判断模块”具体可以用于，调用cometd服务，根据cometd服务判断业务轨迹标识是否存在于预设订阅业务标识库中。

在再一种可能的实施方式中，上述“处理模块”具体可以用于，根据cometd服务将业务轨迹标识对应的轨迹日志转换为待推送消息。

在再一种可能的实施方式中，在不存在的情况下，上述“处理模块”还可以用于，放弃与业务轨迹标识对应的轨迹日志。

在再一种可能的实施方式中，上述“处理模块”还可以用于，确定“预设订阅业务标识库”，通过用户端接收用户创建的预设订阅业务标识库，预设订阅业务标识库中包括至少一个预设订阅业务标识。

第三方面，本申请实施例提供了一种消息处理的设备，该设备包括处理器以及存储有计算机程序指令的存储器；

处理器执行计算机程序指令时实现如第一方面任意一项的业务开通和编排的方法。

本申请，无需进行一边存储一边显示，实现了消息不落地直接送达订阅的客户端，缩短了从数据生成到数据展现的时间间隔；根据业务轨迹标识精确定位，根据轨迹日志展示跟踪业务处理轨迹，提高了处理速度，减少人工等待，达到实时跟踪、多客户端界面同时跟踪的效果。此外，该方法可以支持多个订阅的客户端同时监控同一笔的业务轨迹，以提升用户体验感。

第四方面，本申请实施例提供了一种计算机可读存储介质，包括指令，当其在计算机上运行时，使得计算机执行如第一方面任意一项的方法。

第五方面，本申请实施例提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行如第一方面任意一项的方法。

附图说明

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

图1是本申请一个实施例提供的一种消息处理的技术架构示意图；

图2是本申请一个实施例提供的一种消息处理的方法的流程图；

图3是本申请一个实施例提供的一种消息处理的方法的数据流示意图；

图4是本申请一个实施例提供的一种消息处理的装置的结构示意图；

图5是本申请一个实施例提供的一种消息处理的设备的结构示意图。

具体实施方式

下面将详细描述本申请的各个方面的特征和示例性实施例，为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及具体实施例，对本申请进行进一步详细描述。应理解，此处所描述的具体实施例仅被配置为解释本申请，并不被配置为限定本申请。对于本领域技术人员来说，本申请可以在不需要这些具体细节中的一些细节的情况下实施。下面对实施例的描述仅仅是为了通过示出本申请的示例来提供对本申请更好的理解。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括……”限定的要素，并不排除在包括要素的过程、方法、物品或者设备中还存在另外的相同要素。

首先，为了方便理解本申请中涉及的内容，先介绍一下，cometd服务，该cometd(又称“comet”)是一个基于http，并且使用ajax推技术的事件路由总线程序。结合图1对本申请应用的技术架构作出一定的解释，服务端接收客户端(可以理解为订阅端)订阅带有业务轨迹标识的预设订阅业务标识库，预设订阅业务标识库包括至少一个预设订阅业务标识(例如：订阅业务轨迹标识为a和d的轨迹日志)，然后，服务端接收多个县市级的客户端(例如：客户端a、b、c和d)建立业务轨迹日志指令，该业务轨迹日志包括业务轨迹标识(例如：a、b、c和d)，服务端将同一笔业务轨迹标识的轨迹日志汇总到一起，将业务轨迹标识对应的轨迹日志转换为待推送消息，以便于基于cometd服务将待推送消息向订阅业务轨迹标识的客户端推送(例如：订阅的是业务轨迹标识为a和d的轨迹日志，在推送的时候，仅推送a和d的轨迹日志，当然，在另外的一种可能实现的方式中，在推送a和d对应的轨迹日志之后，还可以推送b和c对应的轨迹日志)以便于通过web界面可以同时订阅和展示同一笔轨迹日志。可以理解的是，本申请涉及到两个客户端，其中，订阅业务且向订阅业务轨迹标识的客户端对应的是订阅端，接受的数据源即客户端a、b、c和d一般指的是子公司对应的客户端。

本申请为了多客户端实时跟踪某一笔业务处理轨迹，采用cometd消息推送技术，缩短了数据生成到数据展现之间的耗时。

下面将结合图2对本方案具体的方法做出一定的解释。

图2是本申请一个实施例提供的一种消息处理的方法的流程图。

如图2所示，该消息处理的方法具体可以包括s210-s240，步骤中的内容如下所示：

s210：接收业务指令，根据业务指令生成对应的业务轨迹日志，业务轨迹日志用于记录业务指令的生命周期。

具体地，在一种可能的实施方式中，在该步骤之前，还可以包括：通过客户端接收用户创建的预设订阅业务标识库，预设订阅业务标识库包括至少一个预设订阅业务标识。

其中，涉及业务轨迹日志，具体可以理解为记录一个问题从开始建立到该问题已经被处理的过程，在记录时，包括该问题经过的轨迹(即该问题到了哪几个相应的平台被处理)，例如：问题1，建立时间：2018年12月1日；第一次处理：在平台1，状态：已处理；已到平台2，状态：未处理。

s220：解析轨迹日志，确定轨迹日志中的业务轨迹标识。

具体地，按照预设轨迹日志解析规则解析轨迹日志，确定轨迹日志中的业务轨迹标识。

在一种可能的实施方式中，在该步骤之前，还可以包括：将业务轨迹日志的状态从待处理状态修改为已处理状态。然后，在业务轨迹日志的状态为已处理状态的情况下，解析轨迹日志，确定轨迹日志中的业务轨迹标识。

在另一种可能的实施方式中，在该步骤之前，还可以包括：按照时间顺序在业务指令的列表中缓存业务轨迹日志。然后，按照时间顺序解析业务指令的列表中缓存的业务轨迹日志，确定轨迹日志中的业务轨迹标识。

需要说明的是，可以结合上述两种可能的实施方式，即在另一种可能的实施方式中，在该步骤之前，还可以包括：将业务轨迹日志的状态从待处理状态修改为已处理状态；按照时间顺序在业务指令的列表中缓存业务轨迹日志；然后，按照时间顺序解析业务指令的列表中缓存的业务轨迹日志，确定轨迹日志中的业务轨迹标识。

或者，在又一种可能的实施方式中，在该步骤之前，还可以包括：按照时间顺序在业务指令的列表中缓存业务轨迹日志；按照时间顺序在业务指令的列表中缓存业务轨迹日志。然后，按照时间顺序解析业务指令的列表中缓存的业务轨迹日志，确定轨迹日志中的业务轨迹标识。

s230：判断业务轨迹标识是否存在于预设订阅业务标识库中。

具体地，调用cometd服务，根据cometd服务判断业务轨迹标识是否存在于预设订阅业务标识库中。

判断过程有两种可能性，第一种可能性就是在存在的情况下，而该情况有包括两种可能的方式：即第一种可能的方式，s240：在存在的情况下，将业务轨迹标识对应的轨迹日志转换为待推送消息，以便于基于cometd服务将待推送消息向订阅业务轨迹标识的用户端推送。第二种可能的方式，根据cometd服务将业务轨迹标识对应的轨迹日志转换为待推送消息，以便于基于cometd服务将待推送消息向订阅业务轨迹标识的用户端推送。

第二种可能性是不存在的情况下，放弃与业务轨迹标识对应的轨迹日志。

综上，需要说明的是，上述预设订阅业务标识库基于以下步骤确定：通过用户端接收用户创建的预设订阅业务标识库，预设订阅业务标识库包括至少一个预设订阅业务标识。可以理解的是，因为通过用户端接收用户创建的预设订阅业务标识库，所以，在基于cometd服务向用户端推送时，是根据预设订阅业务标识将待推送消息向对应的用户端发送的。

上述方式，改变了传统定时查询对应的处理消息的方法，本申请采用了数据推送方式，缩短了处理速度；该方法无需进行一边存储一边显示，实现了消息不落地直接送达订阅的客户端，缩短了从数据生成到数据展现的时间间隔；此外，该方法可以支持多个订阅的客户端同时监控同一笔的业务轨迹，以提升用户体验感。

具体的，根据上述的方法，本申请实施例提供一种具体的例子，以便于理解本申请提供的消息处理的方法。结合图3进行详细说明。

图3是本申请一个实施例提供的一种消息处理的方法的数据流示意图。

如图3所示，通过小信业务问题登记，服务端业务处理轨迹举例说明。具体可以包括如下步骤：

首先，服务端通过客户端接收订阅带有业务轨迹标识的先关信息。具体地，步骤301：服务端接收在“小信业务问题”登记界面，一条申告问题对应的对应的跟踪唯一标识(即业务轨迹标识)，以便于服务端通过相似度匹配规则归类登记问题分类。

步骤302：服务端通过轨迹跟踪界面，接收被跟踪的业务轨迹标识，即在cometd服务创建业务轨迹标识的channel标题，并订阅此channel标题，为cometd服务精准推送消息提供依据。可以理解的是，该步骤中，channel标题相当于预设订阅业务标识，预设订阅业务标识库包括至少一个预设订阅业务标识。

然后，服务端接收业务指令，根据业务指令生成对应的业务轨迹日志，业务轨迹日志用于记录业务指令的生命周期。

步骤303：业务轨迹日志的生成，其中，业务服务处理过程中，业务处理的状态及内容发生变更时，同步发送业务轨迹日志到kafka/jms日志服务，kafka/jms日志服务按时序在消息通道中缓存轨迹日志，供数据采集器处理业务轨迹日志。

步骤304：agent采集处理程序从kafka/jms日志服务接收业务轨迹日志，agent采集处理程序接收业务轨迹日志后，日志服务更新缓存业务轨迹日志状态并移出待消费列表序列至已消费列表序列。

步骤305：agent采集处理程序按预制轨迹日志解析规则解析一条业务轨迹日志，获取此条信息的业务轨迹标识。

步骤306：agent采集处理程序查询cometd服务，判断订阅的channel标题是否与业务轨迹标识相同与,如果不相同，放弃此条数据。如果相同，则将业务轨迹标识对应的轨迹日志转换成channel消息数据。

步骤307：发送channel消息数据，cometd服务将采集器转换的channel消息数据通过消息推送器，推送至该channel消息的所有订阅端。

步骤308：订阅端根据轨迹跟踪界面自动接收已订阅的channel消息数据。

步骤309：轨迹跟踪界面解析channel消息数据转化为轨迹日志，以时间轴为序列依次展现业务轨迹，供订阅过该channel消息的客服人员实时查看业务处理进展。

通过上述方法可以在大数据量的业务轨迹中，精确定位展示跟踪业务处理轨迹，提高了处理速度，减少人工等待，达到实时跟踪、多客户端界面同时跟踪的效果。

图4是本申请一个实施例提供的一种消息处理的装置的结构示意图。

如图4所述，该装置40可以包括：

收发模块401，用于接收业务指令，根据所述业务指令生成对应的业务轨迹日志，所述业务轨迹日志用于记录所述业务指令的生命周期；

解析模块402，用于解析所述轨迹日志，确定所述轨迹日志中的业务轨迹标识；

判断模块403，用于判断所述业务轨迹标识是否存在于预设订阅业务标识库中；

处理模块404，用于在存在的情况下，将所述业务轨迹标识对应的轨迹日志转换为待推送消息，以便于所述处理模块404调用所述收发模块401，基于cometd服务将所述待推送消息向订阅所述业务轨迹标识的用户端推送。

本申请，无需进行一边存储一边显示，实现了消息不落地直接送达订阅的客户端，缩短了从数据生成到数据展现的时间间隔；根据业务轨迹标识精确定位，根据轨迹日志展示跟踪业务处理轨迹，提高了处理速度，减少人工等待，达到实时跟踪、多客户端界面同时跟踪的效果。此外，该方法可以支持多个订阅的客户端同时监控同一笔的业务轨迹，以提升用户体验感。在一种可能的实施方式中，上述“解析模块”具体可以用于，按照预设轨迹日志解析规则解析所述轨迹日志，确定所述轨迹日志中的业务轨迹标识。

处理模块404还可以用于，将所述业务轨迹日志的状态从待处理状态修改为已处理状态。

解析模块402具体可以用于，在所述业务轨迹日志的状态为已处理状态的情况下，解析所述轨迹日志，确定所述轨迹日志中的业务轨迹标识。

该装置40还可以包括：缓存模块405，用于按照时间顺序在所述业务指令的列表中缓存所述业务轨迹日志。

解析模块402具体可以用于，按照所述时间顺序解析所述业务指令的列表中缓存的业务轨迹日志，确定所述轨迹日志中的业务轨迹标识。

判断模块403具体可以用于，调用所述cometd服务，根据所述cometd服务判断所述业务轨迹标识是否存在于预设订阅业务标识库中。

处理模块404具体可以用于，根据所述cometd服务将所述业务轨迹标识对应的轨迹日志转换为待推送消息。

在不存在的情况下，处理模块404还可以用于，放弃与所述业务轨迹标识对应的所述轨迹日志。

处理模块404还可以用于，确定所述“预设订阅业务标识库”，通过所述用户端接收用户创建的预设订阅业务标识库，所述预设订阅业务标识库中包括至少一个预设订阅业务标识。

图5是本申请一个实施例提供的一种消息处理的设备的结构示意图。

如图5所示，该消息处理的设备可以包括处理器501以及存储有计算机程序指令的存储器502。

具体地，上述处理器501可以包括中央处理器(cpu)，或者特定集成电路(applicationspecificintegratedcircuit，asic)，或者可以被配置成实施本申请实施例的一个或多个集成电路。

存储器502可以包括用于数据或指令的大容量存储器。举例来说而非限制，存储器502可包括硬盘驱动器(harddiskdrive，hdd)、软盘驱动器、闪存、光盘、磁光盘、磁带或通用串行总线(universalserialbus，usb)驱动器或者两个或更多个以上这些的组合。在合适的情况下，存储器502可包括可移除或不可移除(或固定)的介质。在合适的情况下，存储器502可在综合网关设备的内部或外部。在特定实施例中，存储器502是非易失性固态存储器。在特定实施例中，存储器502包括只读存储器(rom)。在合适的情况下，该rom可以是掩模编程的rom、可编程rom(prom)、可擦除prom(eprom)、电可擦除prom(eeprom)、电可改写rom(earom)或闪存或者两个或更多个以上这些的组合。

处理器501通过读取并执行存储器502中存储的计算机程序指令，以实现上述实施例中的任意一种消息处理的方法。

收发器503，主要用于实现本发明实施例中各模块、装置、单元、用户端或者服务器中的至少两个之间的通信。

在一个示例中，该设备还可包括总线504。其中，如图5所示，处理器501、存储器502和收发器503通过总线504连接并完成相互间的通信。

总线504包括硬件、软件或两者，将上述部件彼此耦接在一起。举例来说而非限制，总线可包括加速图形端口(agp)或其他图形总线、增强工业标准架构(eisa)总线、前端总线(fsb)、超传输(ht)互连、工业标准架构(isa)总线、无限带宽互连、低引脚数(lpc)总线、存储器总线、微信道架构(mca)总线、外围组件互连(pci)总线、pci-express(pci-x)总线、串行高级技术附件(sata)总线、视频电子标准协会局部(vlb)总线或其他合适的总线或者两个或更多个以上这些的组合。在合适的情况下，总线503可包括一个或多个总线。尽管本申请实施例描述和示出了特定的总线，但本申请考虑任何合适的总线或互连。

另外，结合上述实施例中的消息处理的方法，本申请实施例可提供一种计算机存储介质来实现。该计算机存储介质上存储有计算机程序指令；该计算机程序指令被处理器执行时实现上述实施例中的任意一种消息处理的方法。

需要明确的是，本申请并不局限于上文所描述并在图中示出的特定配置和处理。为了简明起见，这里省略了对已知方法的详细描述。在上述实施例中，描述和示出了若干具体的步骤作为示例。但是，本申请的方法过程并不限于所描述和示出的具体步骤，本领域的技术人员可以在领会本申请的精神后，作出各种改变、修改和添加，或者改变步骤之间的顺序。

以上的结构框图中所示的功能块可以实现为硬件、软件、固件或者它们的组合。当以硬件方式实现时，其可以例如是电子电路、专用集成电路(asic)、适当的固件、插件、功能卡等等。当以软件方式实现时，本申请的元素是被用于执行所需任务的程序或者代码段。程序或者代码段可以存储在机器可读介质中，或者通过载波中携带的数据信号在传输介质或者通信链路上传送。“机器可读介质”可以包括能够存储或传输信息的任何介质。机器可读介质的例子包括电子电路、半导体存储器设备、rom、闪存、可擦除rom(erom)、软盘、cd-rom、光盘、硬盘、光纤介质、射频(rf)链路，等等。代码段可以经由诸如因特网、内联网等的计算机网络被下载。

还需要说明的是，本申请中提及的示例性实施例，基于一系列的步骤或者装置描述一些方法或系统。但是，本申请不局限于上述步骤的顺序，也就是说，可以按照实施例中提及的顺序执行步骤，也可以不同于实施例中的顺序，或者若干步骤同时执行。

以上，仅为本申请的具体实施方式，所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、模块和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。应理解，本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本申请的保护范围之内。