CN107277083B - 一种数据交互的处理方法、装置及系统 - Google Patents

Abstract

本申请实施例公开了一种数据交互的处理方法、装置及系统。该方法包括：发送端向消息中间件发送包括业务数据和预设超时处理时间的请求消息；消息中间件向接收端发送请求消息；接收端判断请求消息中的预设超时处理时间是否晚于当前时间；当所述判断的结果为是时，接收端对请求消息中的业务数据进行相应的业务处理；接收端向消息中间件发送业务处理的结果的反馈消息；消息中间件向发送端发送所述反馈消息；发送端基于业务数据的反馈消息执行相应的业务推进处理操作。利用本申请实施例提供的技术方案不仅可以有效保证通信对象对业务数据交互处理结果的最终一致性，以及减少通信对象间的耦合程度，同时还可以解决业务请求流量过大的问题。

Description

一种数据交互的处理方法、装置及系统

技术领域

本申请涉及互联网通信技术领域，特别涉及一种数据交互的处理方法、装置及系统。

背景技术

在互联网通信技术领域中，对象之间往往需要通过数据交互来实现业务的处理。在数据交互的处理过程中，需要保证通信对象之间交互结果的最终一致性。

现有的数据交互的处理技术中，同步数据交互和分布式事务等处理方式可以保证通信对象之间交互结果的最终一致性。在同步数据交互处理方式中，通信对象(发送端和接收端)之间必须要进行同步，这就意味着每个对象的服务必须都是正常运行的，发送端中的发送程序(一种服务)和接收端中的接收程序(同样是一种服务)都一直处于运行状态。这样，就需要增加事后的状态维护机制来应对网络异常等问题，以确保交互结果的一致性。在分布式事务处理方式中，可以通过如两阶段提交协议等方案来保证交互结果的一致性。具体的，需要一个事务管理器作为通信对象之间的协调者，保证发送端和接收端当前交互结果一致，在当前交互结果一致的情况下，发送端和接收端发送才可以进行下一步的业务处理，在事务管理器确定所述当前交互结果一致前，发送端和接收端需要进行等待，无法异步处理其他业务数据。

上述现有的同步数据交互处理方式和分布式事务处理方式中，通信对象的独立性都较差，通信对象之间的耦合性强，导致系统业务处理的效率低；且同步数据交互处理方式中的强耦合性会出现因一方流量激增导致另一方无法同时响应同步请求的服务问题。同时同步数据交互处理过程中的状态维护机制和分布式事务处理过程中沉重的事务管理器支持均导致方案实施较为复杂。

发明内容

本申请实施例的目的是提供一种数据交互的处理方法、装置及系统，可以有效保证通信对象对业务数据交互处理结果的最终一致性，同时减少通信对象间的耦合程度。

本申请实施例提供一种数据交互的处理方法、装置及系统是这样实现的：

一种数据交互的处理方法，所述方法包括：

在将初始化状态的业务数据写入数据库之后，发送端向消息中间件发送包括所述业务数据和预设超时处理时间的请求消息；

所述消息中间件收到发送端发送的请求消息后向相应的接收端发送所述请求消息；

接收端判断所述请求消息中的预设超时处理时间是否晚于当前时间；

当所述判断的结果为是时，所述接收端对所述请求消息中的业务数据进行相应的业务处理；

所述接收端向所述消息中间件发送所述业务处理的结果的反馈消息；

所述消息中间件收到接收端发送的反馈消息后向相应的发送端发送所述反馈消息；

所述发送端基于所述业务数据的反馈消息执行相应的业务推进处理操作。

一种数据交互的处理方法，所述方法包括：

在将初始化状态的业务数据写入数据库之后，向消息中间件发送包括所述业务数据和预设超时处理时间的请求消息；

接收所述消息中间件发送的反馈消息，所述反馈消息包括当所述预设超时处理时间晚于接收端当前时间时，接收端对所述请求消息中的业务数据进行的相应的业务处理的结果；

基于所述业务数据的反馈消息执行相应的业务推进处理操作。

一种数据交互的处理方法，所述方法包括：

接收消息中间件发送的包括业务数据和预设超时处理时间的请求消息；

判断所述请求消息中的预设超时处理时间是否晚于当前时间；

当所述判断的结果为是时，对所述请求消息中的业务数据进行相应的业务处理；

向所述消息中间件发送所述业务处理的结果的反馈消息。

一种数据交互的处理方法，所述方法包括：

接收发送端发送的包括业务数据和预设超时处理时间的请求消息；

收到发送端发送的请求消息后向相应的接收端发送所述请求消息；

接收所述接收端发送的反馈消息，所述反馈消息包括当所述预设超时处理时间晚于接收端当前时间时，所述接收端对所述请求消息中的业务数据进行的相应的业务处理的结果；

收到接收端发送的反馈消息后向相应的发送端发送所述反馈消息。

一种数据交互的处理装置，所述装置包括：

第一请求消息发送模块，用于在将初始化状态的业务数据写入数据库之后，向消息中间件发送包括所述业务数据和预设超时处理时间的请求消息；

第一反馈消息接收模块，用于接收所述消息中间件发送的反馈消息，所述反馈消息包括当所述预设超时处理时间晚于接收端当前时间时，接收端对所述请求消息中的业务数据进行的相应的业务处理的结果；

业务推进处理模块，用于基于所述业务数据的反馈消息执行相应的业务推进处理操作。

一种数据交互的处理装置，所述装置包括：

第一请求消息接收模块，用于接收消息中间件发送的包括业务数据和预设超时处理时间的请求消息；

判断模块，用于判断所述请求消息中的预设超时处理时间是否晚于当前时间；

业务处理模块，用于当所述判断模块判断的结果为是时，对所述请求消息中的业务数据进行相应的业务处理；

第一反馈消息发送模块，用于向所述消息中间件发送所述业务处理的结果的反馈消息。

一种数据交互的处理装置，所述装置包括：

第二请求消息接收模块，用于接收发送端发送的包括业务数据和预设超时处理时间的请求消息；

第二请求消息发送模块，用于收到发送端发送的请求消息后向相应的接收端发送所述请求消息；

第三反馈消息接收模块，用于接收所述接收端发送的反馈消息，所述反馈消息包括当所述预设超时处理时间晚于接收端当前时间时，所述接收端对所述请求消息中的业务数据进行的相应的业务处理的结果；

第三反馈消息发送模块，用于收到接收端发送的反馈消息后向相应的发送端发送所述反馈消息。

一种数据交互的处理系统，所述系统包括：发送端、接收端和消息中间件；

所述发送端用于在将初始化状态的业务数据写入数据库之后，向消息中间件发送包括所述业务数据和预设超时处理时间的请求消息；以及用于接收所述消息中间件发送的反馈消息；

所述接收端用于判断所述请求消息中的预设超时处理时间是否晚于当前时间；以及用于当所述判断的结果为是时，对所述请求消息中的业务数据进行相应的业务处理；以及用于向所述消息中间件发送所述业务处理的结果的反馈消息；以及用于基于所述业务数据的反馈消息执行相应的业务推进处理操作；

所述消息中间件用于收到发送端发送的请求消息后向相应的接收端发送所述请求消息；以及用于接收所述接收端发送的包括所述业务处理的结果的反馈消息；以及用于收到接收端发送的反馈消息后向相应的发送端发送所述反馈消息。

本申请实施例通过消息中间件传递包括业务数据和预设超时处理时间的请求消息；后续，接收端通过判断所述请求消息中的预设超时处理时间是否晚于当前时间；且当预设超时处理时间晚于当前时间时，才对所述请求消息中的业务数据进行相应的业务处理，实现了对接收端侧的限流，解决了因发送端流量激增导致接收端无法处理发送端的请求消息而产生的服务问题。接着，再通过消息中间件传递包括所述业务处理的结果的反馈消息，最后，发送端根据所述反馈消息进行相应的业务推进处理。发送端与接收端在数据交互的处理过程中无需直接通信，在保证发送端与接收端对所述业务数据交互处理结果最终一致性的基础上，增强通信系统的独立性，实现对通信系统间的解耦。与现有技术相比，利用本申请实施例提供的技术方案，不仅可以有效保证通信对象对业务数据交互处理结果的最终一致性，以及减少通信对象间的耦合程度，同时还可以解决业务请求流量过大的问题。

附图说明

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

图1是本申请提供的数据交互的处理方法的一种实施例的流程示意图；

图2是本申请提供的业务数据的状态查询的一种实施例的流程示意图；

图3是本申请提供的数据交互的处理方法的另一种实施例的流程示意图；

图4是本申请提供的数据交互的处理方法的另一种实施例的流程示意图；

图5是本申请提供的数据交互的处理方法的另一种实施例的流程示意图；

图6是本申请提供的数据交互的处理装置的一种实施例的结构示意图；

图7是本申请提供的数据交互的处理装置的一种实施例的结构示意图；

图8是本申请提供的数据交互的处理装置的一种实施例的结构示意图；

图9是本申请提供的数据交互的处理系统的一种实施例的结构示意图。

具体实施方式

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

消息中间件(Message Oriented Middleware，MOM，也称为面向消息的中间件)技术，提供了以松散耦合的灵活方式进行消息传递的一种中间件机制。MOM能够实现在不同平台之间的通信，它常被用来屏蔽掉各种平台及协议之间的特性，实现应用程序之间的协同。目前主流的消息中间件产品包括国际商业机器公司(International Business MachinesCorporation，IBM)的MQ Series，东亚银行(Bank of East Asia，BEA)的MessageQ和太阳公司(Sun)的Java消息服务(Java Message Service，JMS)等。MOM包括基于存储和转发的应用之间的异步消息传递或同步消息传递。本申请所述消息中间件可以包括异步消息传递。在异步消息传递中，应用之间彼此不直接通信，而是与作为中介的MOM服务器通信。

以下以几个具体的例子详细说明本申请实施例的具体实现。

以下首先介绍本申请一种数据交互的处理方法的实施例。图1是本申请提供的数据交互的处理方法的一种实施例的流程示意图，本申请提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的系统或客户端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。具体的如图1所示，所述方法可以包括：

S110：在将初始化状态的业务数据写入数据库之后，发送端向消息中间件发送包括所述业务数据和预设超时处理时间的请求消息。

本申请实施例中，当发送端需要进行业务处理时，在将初始化状态的业务数据写入数据库之后，发送端向消息中间件发送包括所述业务数据和预设超时处理时间的请求消息。具体的，所述初始化状态的业务数据可以包括未处理且待发送至所述消息中间件的业务数据。所述预设超时处理时间可以包括根据具体业务场景预先设置的所述业务数据的处理期限时间信息。在一个具体的实施例中，所述预设超时处理时间可以设置为08:32:10。

进一步的，所述方法还可以包括：

所述发送端将向所述消息中间件发送的请求消息中的业务数据的状态由初始化状态推进为处理中状态；以及，当向所述消息中间件发送请求消息失败时，将所述发送请求消息失败的业务数据的状态由处理中状态回滚为初始化状态。

具体的，当所述业务数据的状态为处理中状态时，可以判断所述业务数据已经成功发送至所述消息中间件。具体的，在将初始化状态的业务数据写入数据库之后，所述发送端可以开启本地事务执行发送端将所述业务数据的状态由初始化状态的推进为处理中状态，以及向消息中间件发送包括所述处理中状态的业务数据和预设超时处理时间的请求消息。且当发送请求消息失败时可以通过回滚业务数据的状态，将所述业务数据的状态由处理中状态回滚到初始化状态，保证了在所述发送端侧处于处理中状态的业务数据已经成功发送至消息中间件。

进一步的，所述方法还可以包括：

所述发送端以预设时间周期获取所述回滚为初始化状态的业务数据；

相应的，所述发送端向所述消息中间件发送的请求消息中的业务数据包括所述回滚为初始化状态的业务数据。

在实际应用中，可以能出现因消息中间件故障等导致的请求消息发送失败的情况，这里通过发送端以预设时间周期获取本地初始化状态的业务数据，可以保证未发送的业务数据可以及时的发送出去。具体的，所述预设时间周期可以根据具体的应用场景设置，比如设置为60s。

因此，本申请实施例中将请求消息发送至消息中间件之后，发送端可以异步处理其他业务数据，有效保证发送端侧系统的独立性。

S120：所述消息中间件收到发送端发送的请求消息后向相应的接收端发送所述请求消息。

在本申请实施例中，当所述消息中间件接收到发送端发送的请求消息之后，所述消息中间件可以收到发送端发送的请求消息后向相应的接收端发送所述请求消息。具体的，所述发送所述请求消息可以包括以异步消息传递的方式发送。

S130：接收端判断所述请求消息中的预设超时处理时间是否晚于当前时间。

在本申请实施例中，当所述接收端接收到消息中间件发送的所述请求消息之后，可以判断所述请求消息中的预设超时处理时间是否晚于当前时间。具体的，所述当前时间可以包括所述接收端侧的当前时间。

本申请实施例中通过判断所述请求消息中的预设超时处理时间是否晚于当前时间可以确定出所述请求消息中的业务数据是否已经超过处理期限时间。

此外，在实际应用中，为防止所述请求消息重复投递的情况，所述接收端可以在判断所述请求消息中的预设超时处理时间是否晚于当前时间之前，判断所述请求消息是否已经处理，具体的，可以包括但并不限于利用所述请求消息中业务数据对应的ID的幂等性来判断所述请求消息是否已经处理。

S140：当所述判断的结果为是时，所述接收端对所述请求消息中的业务数据进行相应的业务处理。

本申请实施例中，当步骤S130判断的结果为是时，所述接收端可以对所述请求消息中的业务数据进行相应的业务处理。具体的，在实际应用中，所述预设超时处理时间和所述当前时间可以包括时分秒的表述方式，例如所述预设超时处理时间设置为08:32:10，可以表示为Time_over＝8*3600+32*60+10，假设当前时间为08:31:50，可以表示为Time_now＝8*3600+31*60+50，那么可以得到Time_over>Time_now，相应的，步骤S130的判断结果为预设超时处理时间晚于当前时间，可以说明所述请求消息未超时可以被消费处理，所述接收端可以正常处理后续业务流程。

进一步的，所述方法还可以包括：

当所述判断的结果为否时，所述接收端丢弃所述请求消息。

当步骤S130判断的结果为否时，所述接收端可以丢弃所述请求消息，不响应所述请求消息。具体的，在实际应用中，例如所述预设超时处理时间设置为08:32:10，可以表示为Time_over＝8*3600+32*60+10，假设当前时间为08:32:50，可以表示为Time_now＝8*3600+32*60+50，那么可以得到Time_over<Time_now，相应的，步骤S130的判断结果为预设超时处理时间小于当前时间，可以说明所述请求消息已超时，相应的，所述接收端可以不处理业务直接丢弃所述请求消息。

此外，需要说明的是，本申请实施例中所述预设超时处理时间和所述当前时间的表述方式并不仅限于上述的时分秒的形式，在实际应用中，还可以结合具体的应用场景包括其它表述方式，比如在上述的时分秒的形式中结合日期的表述方式：date_time＝(2016,02,15)，表示2016年02月15日，本申请实施例并不以此为限。相应的，当所述预设超时处理时间和所述当前时间的表述方式中结合日期时，当日期不同时，可以直接利用日期判断所述预设超时处理时间是否晚于当前时间；当日期相同时，可以结合对应的时分秒判断所述预设超时处理时间是否晚于当前时间。

在实际应用中，消息中间件存在发送失败自动重传机制，导致接收端接收到的请求消息中的业务数据可能已经超过了处理期限时间，本申请实施例中通过所述预设超时处理时间的设定，可以保证接收端只处理未超时的业务数据，实现了对接收端侧的限流，解决了因发送端流量激增导致接收端无法处理发送端的请求消息而产生的服务问题。

S150：所述接收端向所述消息中间件发送所述业务处理的结果的反馈消息。

本申请实施例中，在步骤S140之后，所述接收端可以向所述消息中间件发送所述业务处理的结果的反馈消息。具体的，将反馈消息发送至消息中间件之后，接收端可以异步处理其他业务数据，有效保证接收端侧系统的独立性。

S160：所述消息中间件收到接收端发送的反馈消息后向相应的发送端发送所述反馈消息。

本申请实施例中，当消息中间件接收到所述反馈消息之后，所述消息中间件可以收到接收端发送的反馈消息后向相应的发送端发送所述反馈消息。具体的，所述发送所述反馈消息可以包括以异步消息传递的方式发送。

S170：所述发送端基于所述业务数据的反馈消息执行相应的业务推进处理操作。

具体的，当所述发送端进行相应的业务推进处理时，可以进行相应的状态更新以及具体的后续新业务处理。具体的，比如转账业务中，业务数据的初始化状态可以设置为待转账，业务数据的处理中状态可以为转账处理中，在接收到反馈信息之后，所述业务数据的状态可以设置为与所述反馈消息相对应的状态结果，包括转账成功、转账失败等。

进一步的，在实际应用中，会出现因网络波动导致请求消息发送失败或者丢失的异常情况，导致有少量业务数据会长期未进行状态更新(包括长期处于初始化状态和长期处于处理中状态)。说明发送端尚未收到所述业务数据的反馈消息。具体的，导致业务数据会长期未进行状态更新可以包括下述的情况：

接收端处理成功，但还未将反馈消息发送给发送端；

接收端收到请求消息，但处理失败；

接收端未收到请求消息，业务并未被处理，但这个时候已经超过预设超时处理时间后续接收端收到请求消息也不会再处理了，视为处理失败。

针对上述情况，可以通过定期守护机制，查询所述业务数据的真实处理状态，从而确定后续的业务处理方式。如图2所示，图2是本申请提供的业务数据的状态查询的一种实施例的流程示意图。相应的，所述方法还可以包括：

S210：所述发送端以预设状态更新时间为周期获取本地到达所述预设状态更新时间时状态未更新的业务数据。

具体的，所述预设状态更新时间可以预先根据所述业务数据的预设超时处理时间和所述业务数据上次状态更新时间设置的。且所述预设状态更新时间大于等于业务数据的处理期限时间。具体的，例如业务数据A的预设超时处理时间为08:32:03，所述业务数据A上次状态更新时间为08:31:58，可以判断所述业务数据A的处理期限时间为5s，相应的，所述预设状态更新时间可以设置为大于等于5s。

此外，本申请实施例中所述预设状态更新时间大于所述预设时间周期，优选的，所述预设状态更新时间远大于所述预设时间周期。

S220：所述发送端向所述接收端发送所述状态未更新的业务数据的状态查询消息。

S230：所述接收端查询所述状态未更新的业务数据在本地的当前状态。

S240：所述接收端向所述发送端发送所述当前状态的反馈消息。

本申请实施例中，通过业务数据的状态查询的处理，发送端可以及时获取异常情况下少量长期未进行状态更新的业务数据的当前处理情况，保证可以及时对所述业务数据进行相应的处理。

由此可见，本申请一种数据交互的处理方法的实施例通过消息中间件传递包括业务数据和预设超时处理时间的请求消息；后续，接收端通过判断所述请求消息中的预设超时处理时间是否晚于当前时间；且当预设超时处理时间晚于当前时间时，才对所述请求消息中的业务数据进行相应的业务处理，实现了对接收端侧的限流，解决了因发送端流量激增导致接收端无法处理发送端的请求消息而产生的服务问题。接着，再通过消息中间件传递包括所述业务处理的结果的反馈消息，最后，发送端根据所述反馈消息进行相应的业务推进处理。发送端与接收端在数据交互的处理过程中无需直接通信，在保证发送端与接收端对所述业务数据交互处理结果最终一致性的基础上，增强通信系统的独立性，实现对通信系统间的解耦。与现有技术相比，利用本申请实施例提供的技术方案，不仅可以有效保证通信对象对业务数据交互处理结果的最终一致性，以及减少通信对象间的耦合程度，同时还可以解决业务请求流量过大的问题。

考虑发送端为主的步骤，以下介绍本申请一种数据交互的处理方法的另一种实施例，图3是本申请提供的数据交互的处理方法的另一种实施例的流程示意图，本申请提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。具体的如图3所示，所述方法可以包括：

S310：在将初始化状态的业务数据写入数据库之后，向消息中间件发送包括所述业务数据和预设超时处理时间的请求消息。

进一步的，所述方法还可以包括：

将向所述消息中间件发送的请求消息中的业务数据的状态由初始化状态推进为处理中状态；以及，当向所述消息中间件发送请求消息失败时，将所述发送请求消息失败的业务数据的状态由处理中状态回滚为初始化状态。

所述方法还可以包括：

以预设时间周期获取所述回滚为初始化状态的业务数据；

相应的，所述向所述消息中间件发送的请求消息中的业务数据包括所述回滚为初始化状态的业务数据。

S320：接收所述消息中间件发送的反馈消息，所述反馈消息包括当所述预设超时处理时间晚于接收端当前时间时，接收端对所述请求消息中的业务数据进行的相应的业务处理的结果。

S330：基于所述业务数据的反馈消息执行相应的业务推进处理操作。

进一步的，所述方法还可以包括：

以预设状态更新时间为周期获取本地到达所述预设状态更新时间时状态未更新的业务数据；

向所述接收端发送所述状态未更新的业务数据的状态查询消息；

接收所述接收端发送的所述状态未更新的业务数据在接收端本地的当前状态的反馈消息。

由以上本申请一种数据交互的处理方法的实施例可见，本申请中发送端在将初始化状态的业务数据写入数据库之后，通过向消息中间件发送包括所述业务数据和预设超时处理时间的请求消息，以及通过所述消息中间件接收发送端对所述请求消息中业务数据的处理结果，有效保证了系统的独立性，实现对通信系统间的解耦。同时通过所述预设超时处理时间的设置，可以保证后续接收端只处理未超时的业务数据，实现了对接收端侧的限流，解决了因发送端流量激增导致接收端无法处理发送端的请求消息而产生的服务问题。与现有技术相比，利用本申请实施例提供的技术方案，不仅可以有效保证通信对象对业务数据交互处理结果的最终一致性，以及减少通信对象间的耦合程度，同时还可以解决业务请求流量过大的问题。

考虑接收端为主的步骤，以下介绍本申请一种数据交互的处理方法的另一种实施例，图4是本申请提供的数据交互的处理方法的另一种实施例的流程示意图，本申请提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。具体的如图4所示，所述方法可以包括：

S410：接收消息中间件发送的包括业务数据和预设超时处理时间的请求消息。

S420：判断所述请求消息中的预设超时处理时间是否晚于当前时间。

S430：当所述判断的结果为是时，对所述请求消息中的业务数据进行相应的业务处理。

进一步的，所述方法还可以包括：

当所述判断的结果为否时，丢弃所述请求消息。

S440：向所述消息中间件发送所述业务处理的结果的反馈消息。

进一步的，所述方法还可以包括：

接收发送端发送的到达预设状态更新时间状态未更新的业务数据的状态查询消息；

查询所述状态未更新的业务数据在本地的当前状态；

向所述发送端发送所述当前状态的反馈消息。

由以上本申请一种数据交互的处理方法的实施例可见，本申请中接收端通过消息中间件获取包括业务数据和预设超时处理时间的请求消息，以及通过消息中间件向发送端传递包括对所述请求消息中业务数据处理结果的反馈消息，有效保证了系统的独立性，实现对通信系统间的解耦。同时通过判断预设超时处理时间是否晚于当前时间，当预设超时处理时间晚于当前时间，才处理业务数据，实现了对接收端侧的限流，解决了因发送端流量激增导致接收端无法处理发送端的请求消息而产生的服务问题。与现有技术相比，利用本申请实施例提供的技术方案，不仅可以有效保证通信对象对业务数据交互处理结果的最终一致性，以及减少通信对象间的耦合程度，同时还可以解决业务请求流量过大的问题。

考虑消息中间件为主的步骤，以下介绍本申请一种数据交互的处理方法的另一种实施例，图5是本申请提供的数据交互的处理方法的另一种实施例的流程示意图，本申请提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。具体的如图5所示，所述方法可以包括：

S510：接收发送端发送的包括业务数据和预设超时处理时间的请求消息。

S520：收到发送端发送的请求消息后向相应的接收端发送所述请求消息。

S530：接收所述接收端发送的反馈消息，所述反馈消息包括当所述预设超时处理时间晚于接收端当前时间时，所述接收端对所述请求消息中的业务数据进行的相应的业务处理的结果。

S540：收到接收端发送的反馈消息后向相应的发送端发送所述反馈消息。

由以上本申请一种数据交互的处理方法的实施例可见，本申请中消息中间件通过向接收端传递发送端发送的包括业务数据和预设超时处理时间的请求消息，以及通过向发送端传递接收端发送的包括对所述请求消息中业务数据处理结果的反馈消息，有效保证了通信系统的独立性，实现对通信系统间的解耦。与现有技术相比，利用本申请实施例提供的技术方案，不仅可以有效保证通信对象对业务数据交互处理结果的最终一致性，同时可以减少通信对象间的耦合程度。

本申请另一方面还提供一种数据交互的处理装置，图6是本申请提供的数据交互的处理装置的一种实施例的结构示意图，如图6所示，所述装置600可以包括：

第一请求消息发送模块610，可以用于在将初始化状态的业务数据写入数据库之后，向消息中间件发送包括所述业务数据和预设超时处理时间的请求消息；

第一反馈消息接收模块620，可以用于接收所述消息中间件发送的反馈消息，所述反馈消息包括当所述预设超时处理时间晚于接收端当前时间时，接收端对所述请求消息中的业务数据进行的相应的业务处理的结果；

业务推进处理模块630，可以用于基于所述业务数据的反馈消息执行相应的业务推进处理操作。

另一种实施例中，所述装置600还可以包括：

状态推进模块，可以用于将向所述消息中间件发送的请求消息中的业务数据的状态由初始化状态推进为处理中状态；

状态回滚模块，可以用于当向所述消息中间件发送请求消息失败时，将所述发送请求消息失败的业务数据的状态由处理中状态回滚为初始化状态。

另一种实施例中，所述装置600还可以包括：

第一业务数据获取模块，可以用于以预设时间周期获取所述回滚为初始化状态的业务数据；

相应的，所述向所述消息中间件发送的请求消息中的业务数据可以包括所述回滚为初始化状态的业务数据。

另一种实施例中，所述装置600还可以包括：

第二业务数据获取模块，可以用于以预设状态更新时间为周期获取本地到达所述预设状态更新时间时状态未更新的业务数据；

状态查询消息发送模块，可以用于向所述接收端发送所述状态未更新的业务数据的状态查询消息；

第二反馈消息接收模块，可以用于接收所述接收端发送的所述状态未更新的业务数据在接收端本地的当前状态的反馈消息。

本申请还提供一种数据交互的处理装置的另一实施例，图7是本申请提供的数据交互的处理装置的一种实施例的结构示意图，如图7所示，所述装置700可以包括：

第一请求消息接收模块710，可以用于接收消息中间件发送的包括业务数据和预设超时处理时间的请求消息；

判断模块720，可以用于判断所述请求消息中的预设超时处理时间是否晚于当前时间；

业务处理模块730，可以用于当所述判断模块判断的结果为是时，对所述请求消息中的业务数据进行相应的业务处理；

第一反馈消息发送模块740，可以用于向所述消息中间件发送所述业务处理的结果的反馈消息。

另一种实施例中，所述装置700还可以包括：

状态查询消息接收模块，可以用于接收发送端发送的到达预设状态更新时间状态未更新的业务数据的状态查询消息；

状态查询模块，可以用于查询所述状态未更新的业务数据在本地的当前状态；

第二反馈消息发送模块，可以用于向所述发送端发送所述当前状态的反馈消息。

另一种实施例中，所述装置700还可以包括：

请求消息丢弃模块，可以用于当所述判断模块判断的结果为否时，丢弃所述请求消息。

本申请还提供一种数据交互的处理装置的另一实施例，图8是本申请提供的数据交互的处理装置的一种实施例的结构示意图，如图8所示，所述装置800可以包括：

第二请求消息接收模块810，可以用于接收发送端发送的包括业务数据和预设超时处理时间的请求消息；

第二请求消息发送模块820，可以用于收到发送端发送的请求消息后向相应的接收端发送所述请求消息；

第三反馈消息接收模块830，可以用于接收所述接收端发送的反馈消息，所述反馈消息包括当所述预设超时处理时间晚于接收端当前时间时，所述接收端对所述请求消息中的业务数据进行的相应的业务处理的结果；

第三反馈消息发送模块840，可以用于收到接收端发送的反馈消息后向相应的发送端发送所述反馈消息。

本申请还提供一种数据交互的处理系统的实施例，图9是本申请提供的数据交互的处理系统的一种实施例的结构示意图，如图9所示，所述系统900可以包括：发送端910、接收端920和消息中间件930；

所述发送端910可以用于在将初始化状态的业务数据写入数据库之后，向消息中间件发送包括所述业务数据和预设超时处理时间的请求消息；以及可以用于接收所述消息中间件发送的反馈消息；

所述接收端920可以用于判断所述请求消息中的预设超时处理时间是否晚于当前时间；以及可以用于当所述判断的结果为是时，对所述请求消息中的业务数据进行相应的业务处理；以及可以用于向所述消息中间件发送所述业务处理的结果的反馈消息；以及可以用于基于所述业务数据的反馈消息执行相应的业务推进处理操作；

所述消息中间件930可以用于收到发送端发送的请求消息后向相应的接收端发送所述请求消息；以及可以用于接收所述接收端发送的包括所述业务处理的结果的反馈消息；以及可以用于收到接收端发送的反馈消息后向相应的发送端发送所述反馈消息。

由此可见，本申请一种数据交互的处理方法、装置及系统的实施例通过消息中间件传递包括业务数据和预设超时处理时间的请求消息；后续，接收端通过判断所述请求消息中的预设超时处理时间是否晚于当前时间；且当预设超时处理时间晚于当前时间时，才对所述请求消息中的业务数据进行相应的业务处理，实现了对接收端侧的限流，解决了因发送端流量激增导致接收端无法处理发送端的请求消息而产生的服务问题。接着，再通过消息中间件传递包括所述业务处理的结果的反馈消息，最后，发送端根据所述反馈消息进行相应的业务推进处理。发送端与接收端在数据交互的处理过程中无需直接通信，在保证发送端与接收端对所述业务数据交互处理结果最终一致性的基础上，增强通信系统的独立性，实现对通信系统间的解耦。与现有技术相比，利用本申请实施例提供的技术方案，不仅可以有效保证通信对象对业务数据交互处理结果的最终一致性，以及减少通信对象间的耦合程度，同时还可以解决业务请求流量过大的问题。

尽管本申请内容中提到发送端、接收端和消息中间件之间的数据交互、处理的描述，但是，本申请并不局限于必须是完全标准或者所提及的数据处理应用环境的情况。本申请中各个实施例中所涉及的上述描述仅是本申请中的一些实施例中的应用。当然，在符合本申请上述各实施例的中所述的处理方法步骤的其他无创造性的变形，仍然可以实现相同的申请，在此不再赘述。

虽然本申请提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的手段可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或客户端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。

上述实施例阐明装置或模块，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本申请时可以把各模块的功能在同一个或多个软件和/或硬件中实现，也可以将实现同一功能的模块由多个子模块或子单元的组合实现。

本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内部包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构、类等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

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

本说明书中的各个实施例采用递进的方式描述，各个实施例之间相同或相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。本申请可用于众多通用或专用的计算机系统环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、移动通信终端、多处理器系统、基于微处理器的系统、可编程的电子设备、网络PC、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。

虽然通过实施例描绘了本申请，本领域普通技术人员知道，本申请有许多变形和变化而不脱离本申请的精神，希望所附的权利要求包括这些变形和变化而不脱离本申请的精神。

Claims (12)

1.一种数据交互的处理方法，其特征在于，所述方法包括：

在将初始化状态的业务数据写入数据库之后，发送端向消息中间件发送包括所述业务数据和预设超时处理时间的请求消息；

所述消息中间件收到发送端发送的请求消息后向相应的接收端发送所述请求消息；

接收端判断所述请求消息中的业务数据是否已经处理；

当所述判断的结果为否时，接收端判断所述请求消息中的预设超时处理时间是否晚于当前时间；

当所述判断的结果为是时，所述接收端对所述请求消息中的业务数据进行相应的业务处理；

所述接收端向所述消息中间件发送所述业务处理的结果的反馈消息；

所述消息中间件收到接收端发送的反馈消息后向相应的发送端发送所述反馈消息；

所述发送端基于所述业务数据的反馈消息执行相应的业务推进处理操作；

所述发送端以预设状态更新时间为周期获取本地到达所述预设状态更新时间时状态未更新的业务数据；

所述发送端向所述接收端发送所述状态未更新的业务数据的状态查询消息；

所述接收端查询所述状态未更新的业务数据在本地的当前状态；

所述接收端向所述发送端发送所述当前状态的反馈消息。

2.一种数据交互的处理方法，其特征在于，所述方法包括：

在将初始化状态的业务数据写入数据库之后，向消息中间件发送包括所述业务数据和预设超时处理时间的请求消息；

接收所述消息中间件发送的反馈消息，所述反馈消息包括当所述请求消息中的业务数据未处理时，且当所述预设超时处理时间晚于接收端当前时间时，接收端对所述请求消息中的业务数据进行的相应的业务处理的结果；

基于所述业务数据的反馈消息执行相应的业务推进处理操作；

以预设状态更新时间为周期获取本地到达所述预设状态更新时间时状态未更新的业务数据；

向所述接收端发送所述状态未更新的业务数据的状态查询消息；

接收所述接收端发送的所述状态未更新的业务数据在接收端本地的当前状态的反馈消息。

3.根据权利要求2所述的方法，其特征在于，所述方法还包括：

将向所述消息中间件发送的请求消息中的业务数据的状态由初始化状态推进为处理中状态；以及，当向所述消息中间件发送请求消息失败时，将所述发送请求消息失败的业务数据的状态由处理中状态回滚为初始化状态。

4.根据权利要求3所述的方法，其特征在于，所述方法还包括：

以预设时间周期获取所述回滚为初始化状态的业务数据；

相应的，所述向所述消息中间件发送的请求消息中的业务数据包括所述回滚为初始化状态的业务数据。

5.一种数据交互的处理方法，其特征在于，所述方法包括：

接收消息中间件发送的包括业务数据和预设超时处理时间的请求消息；

接收端判断所述请求消息中的业务数据是否已经处理；

当所述判断的结果为否时，判断所述请求消息中的预设超时处理时间是否晚于当前时间；

当所述判断的结果为是时，对所述请求消息中的业务数据进行相应的业务处理；

向所述消息中间件发送所述业务处理的结果的反馈消息；

接收发送端发送的到达预设状态更新时间状态未更新的业务数据的状态查询消息；

查询所述状态未更新的业务数据在本地的当前状态；

向所述发送端发送所述当前状态的反馈消息。

6.根据权利要求5所述的方法，其特征在于，所述方法还包括：

当所述判断的结果为否时，丢弃所述请求消息。

7.一种数据交互的处理装置，其特征在于，所述装置包括：

第一请求消息发送模块，用于在将初始化状态的业务数据写入数据库之后，向消息中间件发送包括所述业务数据和预设超时处理时间的请求消息；

第一反馈消息接收模块，用于接收所述消息中间件发送的反馈消息，所述反馈消息包括当所述请求消息中的业务数据未处理时，且当所述预设超时处理时间晚于接收端当前时间时，接收端对所述请求消息中的业务数据进行的相应的业务处理的结果；

业务推进处理模块，用于基于所述业务数据的反馈消息执行相应的业务推进处理操作；

第二业务数据获取模块，可以用于以预设状态更新时间为周期获取本地到达所述预设状态更新时间时状态未更新的业务数据；

状态查询消息发送模块，可以用于向所述接收端发送所述状态未更新的业务数据的状态查询消息；

第二反馈消息接收模块，可以用于接收所述接收端发送的所述状态未更新的业务数据在接收端本地的当前状态的反馈消息。

8.根据权利要求7所述的装置，其特征在于，所述装置还包括：

状态推进模块，用于将向所述消息中间件发送的请求消息中的业务数据的状态由初始化状态推进为处理中状态；

状态回滚模块，用于当向所述消息中间件发送请求消息失败时，将所述发送请求消息失败的业务数据的状态由处理中状态回滚为初始化状态。

9.根据权利要求8所述的装置，其特征在于，所述装置还包括：

第一业务数据获取模块，用于以预设时间周期获取所述回滚为初始化状态的业务数据；

相应的，所述向所述消息中间件发送的请求消息中的业务数据包括所述回滚为初始化状态的业务数据。

10.一种数据交互的处理装置，其特征在于，所述装置包括：

第一请求消息接收模块，用于接收消息中间件发送的包括业务数据和预设超时处理时间的请求消息；

判断模块，用于判断所述请求消息中的业务数据是否已经处理；当所述判断的结果为否时，判断所述请求消息中的预设超时处理时间是否晚于当前时间；

业务处理模块，用于当所述判断模块判断的结果为是时，对所述请求消息中的业务数据进行相应的业务处理；

第一反馈消息发送模块，用于向所述消息中间件发送所述业务处理的结果的反馈消息；

状态查询消息接收模块，用于接收发送端发送的到达预设状态更新时间状态未更新的业务数据的状态查询消息；

状态查询模块，用于查询所述状态未更新的业务数据在本地的当前状态；

第二反馈消息发送模块，用于向所述发送端发送所述当前状态的反馈消息。

11.根据权利要求10所述的装置，其特征在于，所述装置还包括：

请求消息丢弃模块，用于当所述判断模块判断的结果为否时，丢弃所述请求消息。

12.一种数据交互的处理系统，其特征在于，所述系统包括：发送端、接收端和消息中间件；

所述发送端用于在将初始化状态的业务数据写入数据库之后，向消息中间件发送包括所述业务数据和预设超时处理时间的请求消息；以及用于接收所述消息中间件发送的反馈消息；以预设状态更新时间为周期获取本地到达所述预设状态更新时间时状态未更新的业务数据；向所述接收端发送所述状态未更新的业务数据的状态查询消息；

所述接收端用于判断所述请求消息中的业务数据是否已经处理；当所述判断的结果为否时，判断所述请求消息中的预设超时处理时间是否晚于当前时间；以及用于当所述判断的结果为是时，对所述请求消息中的业务数据进行相应的业务处理；以及用于向所述消息中间件发送所述业务处理的结果的反馈消息；以及用于基于所述业务数据的反馈消息执行相应的业务推进处理操作；查询所述状态未更新的业务数据在本地的当前状态；向所述发送端发送所述当前状态的反馈消息；

所述消息中间件用于收到发送端发送的请求消息后向相应的接收端发送所述请求消息；以及用于接收所述接收端发送的包括所述业务处理的结果的反馈消息；以及用于收到接收端发送的反馈消息后向相应的发送端发送所述反馈消息。

Images