CN117640659A - 统一消息数据处理方法、装置及存储介质 - Google Patents

Abstract

本申请实施例提供一种统一消息数据处理方法、装置及存储介质，所述方法包括：获取消息发送端发送的统一消息并确定所述统一消息的消息类型，所述消息类型包括事件类；在所述统一消息的消息类型为事件类的情况下，基于所述消息发送端发送的确认结果向消息接收端发送所述统一消息。本申请实施例提供的统一消息数据处理方法、装置及存储介质，通过获取消息发送端发送的统一消息并确定统一消息的消息类型，在统一消息的消息类型为事件类的情况下，根据消息发送端发送的确认结果向消息接收端发送统一消息，从而可以提高消息发送端和消息接收端之间的消息一致性，保证数据同步。

Description

统一消息数据处理方法、装置及存储介质

技术领域

本申请涉及通信技术领域，尤其涉及一种统一消息数据处理方法、装置及存储介质。

背景技术

在互联网环境下，应用系统总会面对数据量的增长而带来的系统压力，为了缓解系统的压力目前大多互联网企业普遍采用分布式系统架构。随着分布式服务架构的流行与普及，原来在单包应用中执行的多个逻辑操作，现在被拆分成了多个服务之间的远程调用。虽然服务化为我们的系统带来了水平伸缩能力，然而随之而来的挑战就是分布式场景中数据同步的问题。每个服务之间都是独立的体系，他们彼此之间不在同一个数据库环境中，假如A服务执行成功了，B服务执行却失败了，而A的数据此时已经提交，那么最终就会导致两边数据不同步的问题。

发明内容

针对上述技术问题，本申请实施例提供一种统一消息数据处理方法、装置及存储介质。

第一方面，本申请实施例提供一种统一消息数据处理方法，包括：

获取消息发送端发送的统一消息并确定所述统一消息的消息类型，所述消息类型包括事件类；

在所述统一消息的消息类型为事件类的情况下，基于所述消息发送端发送的确认结果向消息接收端发送所述统一消息。

在一些实施例中，所述在所述统一消息的消息类型为事件类的情况下，基于所述消息发送端发送的确认结果发送所述统一消息，包括：

在所述统一消息的消息类型为事件类的情况下，向所述消息发送端发送确认消息，所述确认消息用于确认是否发送所述统一消息；

接收所述消息发送端发送的确认结果；

根据所述确认结果的指示发送所述统一消息。

在一些实施例中，所述向所述消息发送端发送确认消息，包括：

根据预设周期，获取创建超时的统一消息；

基于所述创建超时的统一消息，确定消息发送端的接口；

基于所述消息发送端的接口向所述消息发送端发送确认消息。

在一些实施例中，所述方法还包括：

在所述统一消息的消息类型为事件类的情况下，接收所述消息接收端发送的处理结果；

基于所述处理结果，确定所述统一消息已完成发送并停止重复发送所述统一消息。

在一些实施例中，所述方法还包括：

在所述统一消息的发送次数达到预设值的情况下，停止发送所述统一消息并标记所述统一消息为未完成。

在一些实施例中，所述方法还包括：

存储未完成的统一消息。

第二方面，本申请实施例还提供一种统一消息数据处理装置，包括：

第一获取模块，用于获取消息发送端发送的统一消息并确定所述统一消息的消息类型，所述消息类型包括事件类；

第一发送模块，用于在所述统一消息的消息类型为事件类的情况下，基于所述消息发送端发送的确认结果向消息接收端发送所述统一消息。

在一些实施例中，所述第一发送模块，包括：

第一发送子模块，用于在所述统一消息的消息类型为事件类的情况下，向所述消息发送端发送确认消息，所述确认消息用于确认是否发送所述统一消息；

第一接收子模块，用于接收所述消息发送端发送的确认结果；

第二发送子模块，用于根据所述确认结果的指示发送所述统一消息。

在一些实施例中，所述第一接收子模块，包括：

第一获取单元，用于根据预设周期，获取创建超时的统一消息；

第一确定单元，用于基于所述创建超时的统一消息，确定消息发送端的接口；

第一发送单元，用于基于所述消息发送端的接口向所述消息发送端发送确认消息。

在一些实施例中，所述统一消息数据处理装置还包括：

第一接收模块，用于在所述统一消息的消息类型为事件类的情况下，接收所述消息接收端发送的处理结果；

第一确定模块，用于基于所述处理结果，确定所述统一消息已完成发送并停止重复发送所述统一消息。

在一些实施例中，所述统一消息数据处理装置还包括：

第一处理模块，用于在所述统一消息的发送次数达到预设值的情况下，停止发送所述统一消息并标记所述统一消息为未完成。

在一些实施例中，所述统一消息数据处理装置还包括：

第一存储模块，用于存储未完成的统一消息。

第三方面，本申请实施例还提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现如上述任一种所述统一消息数据处理方法。

第四方面，本申请实施例还提供一种非暂态计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如上述任一种所述统一消息数据处理方法。

第五方面，本申请实施例还提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现如上述任一种所述统一消息数据处理方法。

本申请实施例提供的统一消息数据处理方法、装置及存储介质，通过获取消息发送端发送的统一消息并确定统一消息的消息类型，在统一消息的消息类型为事件类的情况下，根据消息发送端发送的确认结果向消息接收端发送统一消息，从而可以提高消息发送端和消息接收端之间的消息一致性，保证数据同步。

附图说明

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

图1是基于MQ中间件实现数据同步的流程示意图；

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

图3是本申请实施例提供的统一消息数据处理系统的架构示意图；

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

图5是本申请实施例提供的电子设备的实体结构示意图。

具体实施方式

在分布式场景中解决业务服务之间的数据同步，传统的有基于XA协议的全局事务，但是这类方案因为需要资源的全局锁定，在互联网应用中数据量并发量大的场景下会导致性能极差；并且各个业务服务都需要支持XA协议资源，代码耦合性高。

还有通过一致性消息的方式来达到服务之间的数据同步。常规的消息方案中都是基于消息队列(Message Queue，MQ)中间件产品ActiveMQ、RabbitMQ、RocketMQ等相应的中间件产品来实现。

图1是基于MQ中间件实现数据同步的流程示意图，如图1所示，在分布式部署的环境下，主动方应用(消息发送端)，消息中间件，被动方应用(消息接收端)都在各自不同的物理环境下，需要通过网络进行通讯，这样就会引入了数据传输的不确定性，导致消息的发送和投递不可靠。在以上流程中每个环节中都有可能存在网络故障，发生了故障以后就会导致主动方应用和被动方应用之间数据不同步。所以要保证主动方应用和被动方应用之间的数据同步，前提是要保证两边的消息一致性。常规MQ队列消息的处理流程无法实现消息发送一致性。

由于各个业务系统之间的独立性，则会导致各个业务服务都是按照自己的方式来管理和构建自身的消息体系，这样会带来几个问题：

1、可扩展性和可维护性差，当根据业务需求需要增加一种新的消息类型，各个服务系统都需要增加相应的对接方案，工作量高后期维护成本大。

2、紧耦合、资源复用率低，各服务之间与消息的通道都是各自对接，当消息通道发生改变时，所有与其连接的服务都需要改变，灵活性差；而且有新的服务系统接入时，消息功能可复用性低。

为解决上述技术问题，本申请实施例通过在发送统一消息之前向消息发送端确认是否进行发送，并根据确认结果发送该统一消息，可以提高消息发送端和消息接收端之间的消息一致性，保证数据同步。

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

图2是本申请实施例提供的统一消息数据处理方法的流程示意图，如图2所示，本申请实施例提供一种统一消息数据处理方法，包括：

步骤201，获取消息发送端发送的统一消息并确定所述统一消息的消息类型，所述消息类型包括事件类。

具体地，在本申请实施例中，统一消息主要分为两大块，通知类消息和事件类消息。通知类消息是满足日常业务对接的第三方如短信，邮件，微信，应用(application，app)推送等等；事件类消息是为了解决平台内部各个服务之间的数据同步。本申请实施例提供的统一消息数据处理方法可以通过统一消息数据处理系统实现，该系统可以包括消息服务单元，消息管理单元，消息监控单元，消息调度单元。

消息生产者即消息发送端可以通过消息服务单元接口把统一消息发送给该系统。统一消息数据处理系统在接收到统一消息后可以先确定该统一消息的消息状态为“预发送”，再根据该统一消息的消息类型执行后续处理。统一消息数据处理系统在接收到统一消息后也可以直接确定该统一消息的消息类型，然后执行后续处理。

步骤202，在所述统一消息的消息类型为事件类的情况下，基于所述消息发送端发送的确认结果向消息接收端发送所述统一消息。

具体地，在确定该统一消息的消息类型后，如果消息类型为事件类型，则走预发送逻辑；如果消息类型为通知类，则该统一消息直接进入任务池，标记该统一消息的消息状态为“未发送”。

在该统一消息的消息类型为事件类的情况下，接收消息发送端发送的确认结果，并根据确认结果的指示向消息接收端发送该统一消息。

在该统一消息的消息状态为“未发送”的情况下，直接将消息推送给相应的消息接收端接口。

本申请实施例提供的统一消息数据处理方法，通过获取消息发送端发送的统一消息并确定统一消息的消息类型，在统一消息的消息类型为事件类的情况下，根据消息发送端发送的确认结果向消息接收端发送统一消息，从而可以提高消息发送端和消息接收端之间的消息一致性，保证数据同步。

在一些实施例中，所述在所述统一消息的消息类型为事件类的情况下，基于所述消息发送端发送的确认结果发送所述统一消息，包括：

在所述统一消息的消息类型为事件类的情况下，向所述消息发送端发送确认消息，所述确认消息用于确认是否发送所述统一消息；

接收所述消息发送端发送的确认结果；

根据所述确认结果的指示发送所述统一消息。

具体地，在接收到统一消息后，如果确定该统一消息的消息类型为事件类，则可以向消息发送端发送确认消息，用于通知消息发送端消息处理结果，消息发送端根据确认消息进行判断是否进行业务处理，并通过确认结果指示统一消息数据处理系统，统一消息数据处理系统根据接收到的确认结果确定是否发送该统一消息。

在确定发送该统一消息的情况下，可以将该统一消息的消息状态更新为“未发送”，然后直接将消息推送给相应的消息接收端接口。

本申请实施例提供的统一消息数据处理方法，通过在统一消息的消息类型为事件类的情况下，向消息发送端发送确认消息并根据消息发送端发送的确认结果向消息接收端发送统一消息，从而可以提高消息发送端和消息接收端之间的消息一致性，保证数据同步。

在一些实施例中，所述向所述消息发送端发送确认消息，包括：

根据预设周期，获取创建超时的统一消息；

基于所述创建超时的统一消息，确定消息发送端的接口；

基于所述消息发送端的接口向所述消息发送端发送确认消息。

具体地，统一消息数据系统可以根据预设周期将创建超时的“预发送”消息的任务数据以创建时间顺序的方式取出，通过消息关联配置获取生产者消息确认接口，然后通过发送确认消息请求相应的接口确认该统一消息是否发送。

值得一提的是，在统一消息的消息类型为通知类的情况下，本系统也可以根据预设周期将创建超时的“未发送”消息的任务数据以创建时间顺序的方式取出。

本申请实施例提供的统一消息数据处理方法，通过在统一消息的消息类型为事件类的情况下，向消息发送端发送确认消息并根据消息发送端发送的确认结果向消息接收端发送统一消息，从而可以提高消息发送端和消息接收端之间的消息一致性，保证数据同步。

在一些实施例中，所述方法还包括：

在所述统一消息的消息类型为事件类的情况下，接收所述消息接收端发送的处理结果；

基于所述处理结果，确定所述统一消息已完成发送并停止重复发送所述统一消息。

具体地，在消息接收端接收统一消息后，如果该统一消息的消息类型为事件类，则需要向统一消息数据处理系统发送处理结果，本系统根据该处理结果可以将该统一消息的消息状态修改为“已发送”，并停止重复发送该统一消息。在接收到处理结果之前，本系统可以重复发送该统一消息。

本申请实施例提供的统一消息数据处理方法，可以根据消息接收端返回的处理结果确定已完成统一消息的发送，从而可以提高消息发送端和消息接收端之间的消息一致性，保证数据同步。

在一些实施例中，所述方法还包括：

在所述统一消息的发送次数达到预设值的情况下，停止发送所述统一消息并标记所述统一消息为未完成。

具体地，在统一消息的消息类型为事件类的情况下，需要先向消息发送端发送确认消息，确认是否发送该统一消息，在发送该统一消息之后，再接收消息接收端发送的处理结果，根据处理结果停止发送该统一消息。

在向消息发送端发送确认消息的过程中，若消息发送端没有回复确认结果，本系统可以根据预设的时间重复发送确认消息，直至接收到确认结果，或发送次数超过预设值，若发送次数超过预设值，则标记所述统一消息为未完成。

在发送该统一消息之后，若消息接收端没有回复处理结果，本系统可以根据预设的时间重复发送该统一消息，直至接收到处理结果，或发送次数超过预设值，若发送次数超过预设值，则标记所述统一消息为未完成。

本申请实施例提供的统一消息数据处理方法，通过对消息的重发次数进行限定，减少消息重复发送对系统资源的占用，并通过标记未完成的统一消息，可以方便相应人员进行查看和处理。

在一些实施例中，所述方法还包括：

存储未完成的统一消息。

具体地，在向消息发送端发送确认消息的过程中，若消息发送端没有回复确认结果，本系统可以根据预设的时间重复发送确认消息，直至接收到确认结果，或发送次数超过预设值，若发送次数超过预设值，则标记所述统一消息为未完成。

在发送该统一消息之后，若消息接收端没有回复处理结果，本系统可以根据预设的时间重复发送该统一消息，直至接收到处理结果，或发送次数超过预设值，若发送次数超过预设值，则标记所述统一消息为未完成。

本系统可以存储这些未完成的统一消息，相关人员可以查看这些数据，排查问题并进行手动补发此消息。

本申请实施例提供的统一消息数据处理方法，通过对消息的重发次数进行限定，减少消息重复发送对系统资源的占用，并通过标记未完成的统一消息，可以方便相应人员进行查看和处理。

下面以具体的例子，对上述实施例中的方法进行进一步说明。

图3是本申请实施例提供的统一消息数据处理系统的架构示意图，如图3所示，本申请实施例提供的统一消息数据处理系统包括四大块，消息服务单元，消息管理单元，消息监控单元，消息调度单元。

消息服务单元为其他单元提供相应的统一标准的功能接口，包括了消息创建、消息推送、消息配置、消息查询，消息人工补发，消息日志、消息监控等相关功能，整个发明的底层采用的是互联网的微服务架构，所有模块的功能点都是统一调用此单元的接口来完成。

消息管理单元包含消息任务池监控，消息任务日志，消息模板配置，消息关联配置。管理单元的整个过程全部为web页面化配置，不需要人为修改代码，修改后配置实时生效。

其中，消息任务池监控主要是当消息生成后会进入任务池，监控单元线程会对任务池中的消息任务数据进行监控。任务数据生成后会进入任务池，当消息任务被成功消费后离开任务池进入历史日志。当消息没有被成功消费并且该条消息处理已经达到上限，则消息状态会被标记为已死亡，管理员在任务池中看到已死亡消息后，可以手工补发并或找相应的业务人员处理。并且死亡的消息会根据配置通过短信或邮件通知相应的开发或管理人员。

消息任务日志跟消息任务池监控页面一致，主要是作为消息历史日志的保存，方便开发人员和管理人员排查问题。消息成功被消费后会从消息任务池区域迁移到消息历史日志区域。相关人员可以查看消息详情和人工重新补发消息。

整个消息任务由以下几块构成：消息主体：消息主体内容，保存为json格式，由生产方和消费方共同来约定格式内容，是消息任务中的主体部分；队列路由键(routekey)：消息生产方和消费方的关联配置key，并且也是队列名；重发次数：记录调度单元消息发送次数；是否死亡：标记该消息的存活状态，未死亡消息会在监控单元中依据规则自动进行补发，死亡消息则不会补发，会通知相应人员来处理；状态：标记消息发送状态，分为预发送，未发送，已发送三种状态；扩展字段1到3：记录业务相关关键业务字段，用来做后续的查询检索及排查问题。

消息类型主要分为两类，通知类和事件类。事件类消息主要解决生产者和消费者两端之间的数据同步和一致性；通知类消息主要是业务应用给目标客户发送相应的业务信息，如短信，邮件，微信，语音，app推送等，这些不需要保证两端的一致性和同步。所有接入端的消息模板配置都可以通过此模块来完成。

消息模板配置由以下几块构成：number编号：为消息的统一标示，业务系统接入需要记入该标示，在消息调用的时候需要用到此标示；来源：区分消息使用场景的平台，仅仅只是区分；说明：此消息模板使用的功能，主要给相关使用或检索；类型：主要区分事件类消息还是通知类消息；参数：消息体中需要传入的指定参数，参数名称需要跟模板中的变量保持一致，多个中间需要用“&”分隔开；模板：消息体的模板结构，采用的xml结构，底层使用freemarker模板引擎来解析，生产方和消费方在定义传递数据结构的时候互相约束好，配置到此模板里即可。

消息关联配置主要用于配置消息的生产者和消费者之间的关联关系，目的是让调度单元中的消息处理线程感知消息推送的目标接口，以及监控单元中预发送任务线程感知消息确认的接口。此功能模块通过key值的方式，关联双方接口的调用关系和MQ消息队列的对应关系。

消息监控单元在启动时会开启两个线程，一个线程监控消息任务池中的“未发送”状态的任务，一个线程监控消息任务池中的“预发送”任务。

预发送任务线程：线程会每隔60秒的时间扫描一下任务池，将池中的创建时间超过180秒，未死亡，状态为“预发送”的任务数据以创建时间顺序的方式取出前6000条。通过消息关联配置获取生产者消息确认接口，然后通过消息id请求相应的接口确认消息是否发送。如果成功则修改状态为未发送，如果失败则记录重发次数，当重发次数超过5次后，则修改消息为已死亡，相应的人员可以通过消息监控web页面查看死亡消息并做相应的处理。

未发送任务线程：线程会每隔60秒的时间扫描一下任务池，将池中的创建时间超过180秒，未死亡，状态为“未发送”的任务数据以创建时间顺序的方式取出前6000条。遍历每条消息任务数据，首先判断消息重发次数，如果重发次数大于上限的5次，则直接标记此消息任务未已死亡；在次判断是否达到发送消息的时间间隔条件，如果已达到则将消息推给调度单元，如果未达到则直接跳过遍历下一条。

时间间隔条件：设置的同一个消息多次发送的时间间隔分为5段，第一段间隔为0秒，第二段为60秒，第三段为120秒，第四段为300秒，第五段为900。当消息经过这5段的时间总共为23分钟，消息任务都没有成功被消费，那么认为消费者方中存在业务数据或者是服务器等一系列问题，则监控单元就停止继续在对此任务做无效请求，需要相关人员解决问题后，在进入管理单元中的消息任务池监控页面中，进行手工补发消息。

消息调度单元主要分为消息接收线程，消息队列MQ，消息处理线程。

消息接收线程会从消息监控单元中接收状态为“未发送”的消息数据，通过消息中的消息模板id从消息模板配置中获取此消息的模板，然后通过模板及消息中的业务参数组装成消费者需要的请求数据(格式为json)，然后将组装好的数据发送到相应的mq中的队列中。

消息队列MQ采用的是开源产品rabbitmq作为任务通信的数据结构。

消息处理线程中的监听线程会去监听到相应队列中的数据，将数据取出后，通过队列routekey在消息关联配置中找出目标消费者接口，然后将组装好的数据推送到此接口。当消费者成功处理完消息后，消息处理线程就会将任务池中的此消息状态修改为已发送，并将此消息数据从任务池中删除，并存入消息历史日志库。

统一消息主要有两大类，通知类消息和事件类消息。

事件类消息是为了解决异构服务和系统之间的数据同步及一致性，这类消息是需要确保生产端和消费端两端之间的数据一致性，因此在调度单元中的处理完此类型的消息任务后，需要告知监控单元此消息处理情况。

通知类消息是满足日常业务对接的第三方如短信，邮件，微信，app推送等等，这类消息仅仅只是对客户进行通知提醒，没有数据一致性的要求，因此该消息只要发出后本发明就默认此消息已经消费成功。所以当监控单元中将此类消息推送给调度单元后，此类消息的声明周期就已经结束，数据从任务池迁移到历史日志库中。

正常具体流程：

1、消息生产者先通过服务单元接口把消息发送给本发明，消息状态为“预发送”。其中，如果消息类型为事件类型，则执行预发送逻辑；如果消息类型为通知类，则直接进入任务池，状态为“未发送”。

2、本系统收到消息后，把消息保存到消息任务池中。

3、本系统返回消息处理结果，主动方根据返回结果进行判断是否进行业务处理。

若判断成功则执行业务处理，若判断失败：放弃业务处理，流程结束。

4、消息生产者业务处理完成后，把结果(成功或失败)发送给本发明。

5、本系统收到业务操作结果后，根据结果状态进行处理。

若结果为成功则更新任务池中的消息状态为“未发送”，若结果为失败则删除任务池中的消息，结束任务。

6、本系统中的监控单元会将状态为“未发送”的消息推送给调度单元，调度单元会根据消息关联配置以及消息类型做相应的处理：

消息类型为事件类：

将消息推送给相应的消费者接口，需要消费者有处理结果回执数据；

消息类型为通知类：

将消息推送给相应的消费者接口，修改任务池中的消息状态为“已发送”，并将此消息从任务池中删除并迁移至历史日志库。

7、消费者业务处理完成后，如果为事件类消息，则需要向本发明发送确认消息，本发明收到确认消息后将消息状态修改为“已发送”并迁移到历史日志库；如果为通知类消息，则不需要后续操作。

异常处理：

1、当流程1，2，3出现了故障，生产者调用本发明服务单元接口失败，则业务放弃流程直接终止。本发明采用微服务架构，可以横向扩展多台集群来确保服务单元的可靠性。

2、当流程4，5出现了故障，生产者已经完成了业务逻辑，但是本发明没有收到确认，因此任务池中的此条消息任务一直会处于“预发送”状态，如果此消息没有正常处理的话，会导致生产者和消费者之间的数据不一致。此异常处理逻辑：

本系统监控单元中的预发送任务线程会每隔60秒的时间扫描一下任务池，将池中的创建时间超过180秒，未死亡，状态为“预发送”的任务数据以创建时间顺序的方式取出前6000条。通过消息关联配置获取生产者消息确认接口，然后通过消息id请求相应的接口确认消息是否发送。如果成功则修改状态为未发送，如果失败则记录重发次数，当重发次数超过5次后，则修改消息为“已死亡”，相应的人员可以通过消息监控web页面查看死亡消息并做相应的处理。

3、当流程7出现了故障，故障分为两部分，第一部分是消费者没有收到此推送，第二部分是消费者收到此推送并成功处理完在返回确认消息的时候异常，导致此消息任务还处于“未发送”状态。

如果是第一部分问题，监控线程会根据规则在后续不同的时间段在发送5次，如果发完5次后消息还没有被成功消费，本发明就默认消费者存在故障或流程逻辑问题，为了防止过多无效请求浪费服务器资源，监控单元会将此消息标记为“已死亡”，会在管理单元中的web页面的任务池监控数据列表中看到死亡数据，并通知相关人员排查问题修复好消费者后在手动补发消息。

如果是第二部分问题，本发明要求消费者在业务逻辑上需要做重复请求处理(重复请求处理重复提交处理是IT业务系统都需要处理的问题)，如果消费者做了此处理后，后续的重复消息推送其实是无效的，当监控单元对“未发送”消息重新发送超过5次后，会标记为“已死亡”，后续不会重复推送无效消息数据。

本申请实施例提供的统一消息数据处理系统完全独立存在运行，不需要侵入业务系统也不需要依赖业务系统，并且也不影响业务系统的功能及代码侵入，业务系统只需要关注业务本身。这样不仅将消息功能跟业务功能进行解耦，而且整个过程不需要人工干预，完全由本发明自动完成。当消息因某种因素没有投递成功时，本发明会依据一定的逻辑进行自动补偿，也提供了相应的后台页面进行人工补发。

图4是本申请实施例提供的统一消息数据处理装置的结构示意图，如图4所示，本申请实施例提供的统一消息数据处理装置，包括第一获取模块401，第一发送模块402，其中：

第一获取模块，用于获取消息发送端发送的统一消息并确定所述统一消息的消息类型，所述消息类型包括事件类；

第一发送模块，用于在所述统一消息的消息类型为事件类的情况下，基于所述消息发送端发送的确认结果向消息接收端发送所述统一消息。

在一些实施例中，所述第一发送模块，包括：

第一发送子模块，用于在所述统一消息的消息类型为事件类的情况下，向所述消息发送端发送确认消息，所述确认消息用于确认是否发送所述统一消息；

第一接收子模块，用于接收所述消息发送端发送的确认结果；

第二发送子模块，用于根据所述确认结果的指示发送所述统一消息。

在一些实施例中，所述第一接收子模块，包括：

第一获取单元，用于根据预设周期，获取创建超时的统一消息；

第一确定单元，用于基于所述创建超时的统一消息，确定消息发送端的接口；

第一发送单元，用于基于所述消息发送端的接口向所述消息发送端发送确认消息。

在一些实施例中，所述统一消息数据处理装置还包括：

第一接收模块，用于在所述统一消息的消息类型为事件类的情况下，接收所述消息接收端发送的处理结果；

第一确定模块，用于基于所述处理结果，确定所述统一消息已完成发送并停止重复发送所述统一消息。

在一些实施例中，所述统一消息数据处理装置还包括：

第一处理模块，用于在所述统一消息的发送次数达到预设值的情况下，停止发送所述统一消息并标记所述统一消息为未完成。

在一些实施例中，所述统一消息数据处理装置还包括：

第一存储模块，用于存储未完成的统一消息。

具体地，本申请实施例提供的上述统一消息数据处理装置，能够实现上述统一消息数据处理方法实施例所实现的所有方法步骤，且能够达到相同的技术效果，在此不再对本实施例中与方法实施例相同的部分及有益效果进行具体赘述。

图5是本申请实施例提供的电子设备的实体结构示意图，如图5所示，该电子设备可以包括：处理器(processor)510、通信接口(Communications Interface)520、存储器(memory)530和通信总线540，其中，处理器510，通信接口520，存储器530通过通信总线540完成相互间的通信。处理器510可以调用存储器530中的逻辑指令，以执行统一消息数据处理方法，该方法包括：

获取消息发送端发送的统一消息并确定所述统一消息的消息类型，所述消息类型包括事件类；

在所述统一消息的消息类型为事件类的情况下，基于所述消息发送端发送的确认结果向消息接收端发送所述统一消息。

此外，上述的存储器530中的逻辑指令可以通过软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

在一些实施例中，所述在所述统一消息的消息类型为事件类的情况下，基于所述消息发送端发送的确认结果发送所述统一消息，包括：

在所述统一消息的消息类型为事件类的情况下，向所述消息发送端发送确认消息，所述确认消息用于确认是否发送所述统一消息；

接收所述消息发送端发送的确认结果；

根据所述确认结果的指示发送所述统一消息。

在一些实施例中，所述向所述消息发送端发送确认消息，包括：

根据预设周期，获取创建超时的统一消息；

基于所述创建超时的统一消息，确定消息发送端的接口；

基于所述消息发送端的接口向所述消息发送端发送确认消息。

在一些实施例中，所述方法还包括：

在所述统一消息的消息类型为事件类的情况下，接收所述消息接收端发送的处理结果；

基于所述处理结果，确定所述统一消息已完成发送并停止重复发送所述统一消息。

在一些实施例中，所述方法还包括：

在所述统一消息的发送次数达到预设值的情况下，停止发送所述统一消息并标记所述统一消息为未完成。

在一些实施例中，所述方法还包括：

存储未完成的统一消息。

具体地，本申请实施例提供的上述电子设备，能够实现上述执行主体为电子设备的方法实施例所实现的所有方法步骤，且能够达到相同的技术效果，在此不再对本实施例中与方法实施例相同的部分及有益效果进行具体赘述。

另一方面，本发明还提供一种计算机程序产品，所述计算机程序产品包括计算机程序，计算机程序可存储在非暂态计算机可读存储介质上，所述计算机程序被处理器执行时，计算机能够执行上述各方法所提供的统一消息数据处理方法，该方法包括：

获取消息发送端发送的统一消息并确定所述统一消息的消息类型，所述消息类型包括事件类；

在所述统一消息的消息类型为事件类的情况下，基于所述消息发送端发送的确认结果向消息接收端发送所述统一消息

又一方面，本发明还提供一种非暂态计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现以执行上述各方法提供的统一消息数据处理方法，该方法包括：

获取消息发送端发送的统一消息并确定所述统一消息的消息类型，所述消息类型包括事件类；

在所述统一消息的消息类型为事件类的情况下，基于所述消息发送端发送的确认结果向消息接收端发送所述统一消息

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

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

另外需要说明的是：本申请实施例中术语“第一”、“第二”等是用于区别类似的对象，而不用于描述特定的顺序或先后次序。应该理解这样使用的术语在适当情况下可以互换，以便本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施，且“第一”、“第二”所区别的对象通常为一类，并不限定对象的个数，例如第一对象可以是一个，也可以是多个。

本申请实施例中术语“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

本申请实施例中术语“多个”是指两个或两个以上，其它量词与之类似。

本申请中的“基于A确定B”表示确定B时要考虑A这个因素。并不限于“只基于A就可以确定出B”，还应包括：“基于A和C确定B”、“基于A、C和E确定B”、基于“A确定C，基于C进一步确定B”等。另外还可以包括将A作为确定B的条件，例如，“当A满足第一条件时，使用第一方法确定B”；再例如，“当A满足第二条件时，确定B”等；再例如，“当A满足第三条件时，基于第一参数确定B”等。当然也可以是将A作为确定B的因素的条件，例如，“当A满足第一条件时，使用第一方法确定C，并进一步基于C确定B”等。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (10)

1.一种统一消息数据处理方法，其特征在于，包括：

获取消息发送端发送的统一消息并确定所述统一消息的消息类型，所述消息类型包括事件类；

在所述统一消息的消息类型为事件类的情况下，基于所述消息发送端发送的确认结果向消息接收端发送所述统一消息。

2.根据权利要求1所述的统一消息数据处理方法，其特征在于，所述在所述统一消息的消息类型为事件类的情况下，基于所述消息发送端发送的确认结果发送所述统一消息，包括：

在所述统一消息的消息类型为事件类的情况下，向所述消息发送端发送确认消息，所述确认消息用于确认是否发送所述统一消息；

接收所述消息发送端发送的确认结果；

根据所述确认结果的指示发送所述统一消息。

3.根据权利要求2所述的统一消息数据处理方法，其特征在于，所述向所述消息发送端发送确认消息，包括：

根据预设周期，获取创建超时的统一消息；

基于所述创建超时的统一消息，确定消息发送端的接口；

基于所述消息发送端的接口向所述消息发送端发送确认消息。

4.根据权利要求1所述的统一消息数据处理方法，其特征在于，所述方法还包括：

在所述统一消息的消息类型为事件类的情况下，接收所述消息接收端发送的处理结果；

基于所述处理结果，确定所述统一消息已完成发送并停止重复发送所述统一消息。

5.根据权利要求1所述的统一消息数据处理方法，其特征在于，所述方法还包括：

在所述统一消息的发送次数达到预设值的情况下，停止发送所述统一消息并标记所述统一消息为未完成。

6.根据权利要求5所述的统一消息数据处理方法，其特征在于，所述方法还包括：

存储未完成的统一消息。

7.一种统一消息数据处理装置，其特征在于，包括：

第一获取模块，用于获取消息发送端发送的统一消息并确定所述统一消息的消息类型，所述消息类型包括事件类；

第一发送模块，用于在所述统一消息的消息类型为事件类的情况下，基于所述消息发送端发送的确认结果向消息接收端发送所述统一消息。

8.一种电子设备，包括存储器、处理器及存储在所述存储器上并在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现如权利要求1至6任一项所述的统一消息数据处理方法。

9.一种非暂态计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至6任一项所述的统一消息数据处理方法。

10.一种计算机程序产品，包括计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至6任一项所述的统一消息数据处理方法。