一种业务消息处理方法及装置与流程

本申请涉及互联网数据处理技术领域，尤其涉及一种业务消息处理方法及装置。

背景技术：

对于一个复杂的业务系统，其包括很多支撑系统。例如，针对电子商务系统这一复杂的业务系统，其可以包括商品系统、交易系统、物流系统、售后系统、运营系统、商家系统等支撑系统。

为了保障各自支撑系统的稳定性，每一支撑系统对业务的处理大都是通过消息交互的方式来进行的。对于某一个支撑系统来说，经常要订阅很多其他支撑系统的业务消息，这些其他支撑系统既有核心支撑系统，又有非核心支撑系统。

根据一些业务消息(被依赖的业务消息)，执行关联业务处理时，需要使用到其他业务消息(依赖业务消息)。然而，依赖业务消息往往不能先于被依赖的业务消息到达，导致无法执行关联业务处理。例如，对于关注整条业务链路的支撑系统来说，通常是按照实际的业务发生顺序来处理整条链路上的业务消息，也可以说是对整条业务链上的一些业务消息执行关联业务处理，但实际上由于业务消息是异步的，再加上消息中间件服务器有很多，并不能保证订阅的其他支撑系统的业务消息一定会按照期望的业务消息到达顺序到达。下面通过图1所示的电子商务系统的供应链单据中心系统进行说明。

图1中的供应链单据中心系统含有4个支撑系统，分别是交易系统、物流订单系统、仓储作业系统和单据中心系统；其中，单据中心系统为关注整条业务链路的支撑系统，其需要订阅交易系统产生的交易付款消息、物流订单系统产生的物流订单创建消息和仓储作业系统产生的仓储作业订单创建消息。交易 系统对应3个消息中间件服务器，物流订单系统对应2个消息中间件服务器，仓储作业系统对应1个消息中间件服务器；每一支撑系统对应的消息中间件服务器，通常是以集群的形式存在，主要负责将其对应的支撑系统产生的业务消息转发至各个目的系统。根据转发的目的系统对消息的可靠性和及时性的要求不同，可以对对应的各消息中间件服务器设置不同的资源配置，目的系统对消息的可靠性和及时性要求高的，负责转发至该目的系统的消息中间件服务器的资源配置高也就越高，优先级也相应地越高；

图1中，实际的业务发生顺序是：交易付款→物流订单创建→仓储作业订单创建；由于单据中心系统对交易付款→物流订单创建→仓储作业订单创建这一业务链上的仓储作业订单创建消息，执行关联业务处理需要使用交易付款消息和物流订单创建消息，因此，单据中心系统期望的业务消息到达顺序是：交易付款消息→物流订单创建消息→仓储作业订单创建消息；

但实际上，由于发送业务消息的各消息中间件服务器的优先级差异，以及业务消息本身的特定决定了，交易系统、物流系统和仓储作业系统针对同一交易产生的交易付款消息、物流订单创建消息和仓储作业订单创建消息到达单据中心系统时的顺序可能为：物流订单创建消息→仓储作业订单创建消息→交易付款消息、仓储作业订单创建消息→物流订单创建消息→交易付款消息或者交易付款消息→仓储作业订单创建消息→物流订单创建消息等等。

为了确保业务消息能按照期望的业务消息到达顺序到达，进而对被依赖的业务消息执行关联业务处理，现有技术中对业务消息的处理方法如图2所示，包括以下步骤：

步骤201：接收当前业务消息；

针对图1中所示的供应链单据中心系统而言，这里假设接收到的当期业务消息是仓储作业订单创建消息，该仓储作业订单创建消息的依赖业务消息为交易付款消息和物流订单创建消息，并且之前还没有接收到交易付款消息和物流订单创建消息；

步骤202：对该当前业务消息进行独立业务处理；

这里的步骤202进行独立业务处理的目的是，将当前业务消息处理为适合本地处理的业务消息。

步骤203：将当前业务消息保存到可以永久保存的存储设备中；

这里，沿用步骤201中的例子，将接收到的仓储作业订单创建消息保存到存储设备中；

步骤204：判断该当前业务消息是否需要依赖业务消息；若判断结果为是，则执行步骤205；若判断结果为否，则结束。

沿用步骤203的例子，这里判断出仓储作业订单创建消息需要依赖业务消息；

步骤205：判断该当前业务消息的依赖业务消息是否存在；若判断结果为是，则执行步骤206；若判断结果为否，则执行步骤207；

沿用步骤204的例子，这里由于还没有接收到交易付款消息和物流订单创建消息，因此，上述存储设备中并没有存储交易付款消息和物流订单创建消息，也即判断出仓储作业订单创建消息的依赖业务消息不存在，执行步骤207；

步骤206：利用该当前业务消息的依赖业务消息，对该当前业务消息执行关联业务处理。

步骤207：向发送该当前业务消息的消息中间件服务器发送处理失败稍后重试消息，并回滚对该当前业务消息执行的操作。

沿用步骤205的例子，这里，单据中心系统向仓储作业系统发送处理失败稍后重试消息，将在步骤203中存储到存储设备的仓储作业订单创建消息删除。

概括而言，上述方法即为若接收到的当前业务消息的依赖业务消息没有到达，则该当前业务消息就会被回滚。

上述业务消息处理方法可以保证业务消息一定会按照期望的业务消息到达顺序到达，使得可以对被依赖的业务消息进行关联业务处理。然而，该方法存在的缺陷也显而易见，那就是当业务消息量大，且不能保证按照设定顺序到 达时，大量的业务消息会被重试。这将会导致业务消息在消息中间件服务器中的大量堆积，并且直接影响消息中间件服务器的稳定性。如果该消息中间件服务器负责的是核心支撑系统的业务消息的转发，这将会对业务的处理造成更为严重的影响。

技术实现要素：

本申请实施例提供一种业务消息处理方法及装置，用以解决现有技术存在的当业务消息量大且不能保证按照设定顺序到达时，大量的业务消息会被重试，影响消息中间件服务器的稳定性的问题。

一种业务消息处理方法，包括：

接收并保存当前业务消息；

若确定保存的业务消息中不存在该当前业务消息的依赖业务消息，则针对该当前业务消息创建等待任务，其中，该当前业务消息的依赖业务消息包括对该当前业务消息执行关联业务处理时，需要使用的业务消息，创建的所述等待任务用于等待该当前业务消息的依赖业务消息；

将创建的所述等待任务写入到等待任务队列中，并指示至少一个第二节点从等待任务队列中获取等待任务，以及针对获取的每一等待任务，若确定第一节点保存的业务消息中存在该等待任务等待的依赖业务消息，则利用该依赖业务消息，对创建该等待任务时所针对的当前业务消息执行关联业务处理。

一种业务消息处理方法，包括：

从等待任务队列中获取等待任务，其中，每个等待任务是第一节点接收到当前业务消息，并确定保存的业务消息中，不存在该当前业务消息的依赖业务消息时，针对该当前业务消息创建的等待任务，该当前业务消息的依赖业务消息包括对该当前业务消息执行关联业务处理时，需要使用的业务消息，创建的所述等待任务用于等待该当前业务消息的依赖业务消息，所述第一节点将接收到的每一个当前业务消息添加到所述保存的业务消息中；

针对获取的每一等待任务，执行以下操作：

若确定第一节点保存的业务消息中，存在该等待任务等待的依赖业务消息，则利用该依赖业务消息，对创建该等待任务时所针对的当前业务消息执行关联业务处理，并删除该等待任务。

一种业务消息处理装置，包括：

接收模块，用于接收当前业务消息；

保存模块，用于保存接收的当前业务消息；

创建模块，用于若确定保存的业务消息中不存在该当前业务消息的依赖业务消息，则针对该当前业务消息创建等待任务，其中，该当前业务消息的依赖业务消息包括对该当前业务消息执行关联业务处理时，需要使用的业务消息，创建的所述等待任务用于等待该当前业务消息的依赖业务消息；

写入模块，用于将创建的所述等待任务写入到等待任务队列中，并指示至少一个第二节点从等待任务队列中获取等待任务，以及针对获取的每一等待任务，若确定保存的业务消息中存在该等待任务等待的依赖业务消息，则利用该依赖业务消息，对创建该等待任务时所针对的当前业务消息执行关联业务处理。

一种业务消息处理装置，包括：

获取模块，用于从等待任务队列中获取等待任务，其中，每个等待任务是第一节点接收到当前业务消息，并确定保存的业务消息中，不存在该当前业务消息的依赖业务消息时，针对该当前业务消息创建的等待任务，该当前业务消息的依赖业务消息包括对该当前业务消息执行关联业务处理时，需要使用的业务消息，创建的所述等待任务用于等待该当前业务消息的依赖业务消息，所述第一节点将接收到的每一个当前业务消息添加到所述保存的业务消息中；

执行模块，用于针对获取的每一等待任务，执行以下操作：若确定第一节点保存的业务消息中，存在该等待任务等待的依赖业务消息，则利用该依赖业务消息，对创建该等待任务时所针对的当前业务消息执行关联业务处理，并删 除该等待任务。

在本申请实施例的方案中，接收并保存当前业务消息，在确定保存的业务消息中不存在该当前业务消息的依赖业务消息时，针对该当前业务消息创建等待任务，将创建的等待任务写入到等待任务队列中，并指示至少一个第二节点针对等待任务队列中的等待任务，在保存的业务消息中存在等待任务等待的依赖业务消息时，利用该依赖业务消息，对创建该等待任务时所针对的当前业务消息执行关联业务处理。由于在不存在当前业务消息的依赖业务消息时，不是对该当前业务消息进行回滚及重试操作，而是创建等待任务，等待依赖业务消息的到达之后，再进行关联业务处理，因此，当业务消息量大且不能保证按照设定顺序到达时，大量的业务消息不会被重试，业务消息不会因重试而在消息中间件服务器中的大量堆积，提高了消息中间件服务器的稳定性。

附图说明

图1为本申请背景技术提供的供应链单据中心系统的示意图；

图2为本申请背景技术提供的业务消息处理方法流程图；

图3为本申请实施例一提供的业务消息处理方法流程图；

图4为本申请实施例二提供的业务消息处理方法流程图；

图5为本申请实施例三提供的业务消息处理装置的结构示意图；

图6为本申请实施例四提供的业务消息处理装置的结构示意图。

具体实施方式

在本申请实施例的方案中，第一节点接收并保存当前业务消息，在确定保存的业务消息中不存在该当前业务消息的依赖业务消息时，针对该当前业务消息创建等待任务，将创建的等待任务写入到等待任务队列中，并指示至少一个第二节点针对等待任务队列中的等待任务，在保存的业务消息中存在等待任务等待的依赖业务消息时，利用该依赖业务消息，对创建该等待任务时所针对的 当前业务消息执行关联业务处理。由于在不存在当前业务消息的依赖业务消息时，不是对该当前业务消息进行回滚及重试操作，而是创建等待任务，等待依赖业务消息的到达之后，再进行关联业务处理，因此，当业务消息量大且不能保证按照设定顺序到达时，大量的业务消息不会被重试，业务消息不会因重试而在消息中间件服务器中的大量堆积，相对现有技术而言，提高了消息中间件服务器的稳定性；同时，本申请实施例的方案中，由于第一节点指示至少一个第二节点等待依赖业务消息的到达之后，对等待任务进行处理，也即对等待任务进行异步处理，而不是第一节点来处理，这就使得本申请实施例的方案中第一节点对接收的当前业务消息的处理速度并不逊色于现有技术的处理速度。

此外，本申请实施例中的节点(第二节点、第一节点、分布式定时任务节点)可以是指一个按照分布式协议完成一组逻辑的程序。在具体的工程项目中，这里的节点通常是指一个操作系统的进程。这里的第一节点、分布式定时任务节点和至少一个第二节点可以位于同一服务器上，也可以位于不同的服务器上。

以下结合说明书附图对本发明的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本发明，并不用于限定本发明。并且在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

实施例一

如图3所示，其为本申请实施例一提供的业务消息处理方法的流程图，包括以下步骤：

步骤301：第一节点接收当前业务消息；

这里第一节点接收的可以是来自各业务系统的业务消息，这些业务系统之间通常是具有一定的业务依赖关系；

例如，针对图1中所示的供应链单据中心系统，这里的第一节点即可为单据中心系统中的第一节点，接收来自交易系统、物流订单创建系统和仓储作业 系统产生的交易付款消息、物流订单创建消息和仓储订单创建消息。物流订单创建系统是在交易系统创建交易订单之后，在该交易订单的基础上创建的物流订单，而仓储作业系统在物流订单创建系统创建的物流订单的基础上创建的仓储作业订单。

这里将第一节点当前时刻接收到的业务消息称为当前业务消息；

步骤302：第一节点将当前业务消息进行保存；

第一节点将接收到的每一当前业务消息进行保存，可得到保存的业务消息；

这里，还可以对业务消息进行提取处理，提取出业务消息中的业务数据，保存业务数据；

第一节点保存当前业务消息后，不会因该当前业务消息的依赖业务消息不存在而进行删除；

这里的当前业务消息，可以为没有依赖业务消息的当前业务消息，也可以为有依赖业务消息的当前业务消息。

沿用步骤301中所示的例子，若步骤301中接收到的是交易付款消息，该交易付款消息即为没有依赖业务消息的业务消息；若步骤301中接收到的是仓储作业订单创建消息，则该仓储业务订单创建消息即为有依赖业务消息的业务消息，因为对仓储作业订单创建消息执行关联业务处理需要使用交易付款消息和物流订单创建消息。

通常，对于一个业务链，因业务链中的第一个业务的业务对象不同，可以产生很多串消息；为了区分不同的业务消息，可以对每一业务消息设置一个业务标识，用来唯一标识该业务消息，在该业务消息具有依赖业务消息时，将其依赖的各个业务消息的业务标识也携带在这个业务消息中，以便于后续查找；也可以对一串消息设置一个标识，该串消息中的每一业务消息携带该标识，以及自身的业务类型(这里假设该串消息中每一消息的消息类型不同)，在该业务消息具有依赖业务消息时，将其依赖的各个业务消息的业务类型也携带在这 个业务消息中，以便于后续查找；

例如：对于一个交易，对应交易付款消息、物流订单创建消息和仓储作业订单创建消息这一串消息；在多个交易下，会产生多个交易付款消息、多个物流订单创建消息以及多个仓储作业订单创建消息，可以对交易付款消息设置一个交易标识，对仓储作业订单创建消息设置一个仓储作业订单标识，将该仓储作业订单标识携带在仓储作业订单创建消息，并将交易标识和物流订单标识也携带上。或者设置一个交易号，一个交易下产生的交易付款消息、物流订单创建消息和仓储作业订单创建消息均携带该交易号，并在交易付款消息中携带交易业务类型、在物流订单创建消息中携带物流订单类型，在仓储作业订单创建消息中携带仓储作业订单类型；

较佳的，当前业务消息中携带有第一业务标识，或者携带有第一业务标识和至少一个第二业务标识，其中，第一业务标识为该当前业务消息的业务标识，第二业务标识为该当前业务消息的依赖业务消息中包含的业务消息的业务标识；

这里当前业务消息携带的第二业务标识的个数即为该当前业务消息的依赖业务消息中包含的业务消息的个数，后续可以利用该第二业务标识，来查找到该当前业务消息的依赖业务消息。

此外，在上述较佳的方案的基础上，为了提高后续第二节点查找业务消息的查找速度，可以将业务类型相同的业务消息保存在同一张数据表中，也即较佳的，当前业务消息中还携带有第一业务类型，或者第一业务类型和至少一个第二业务类型，其中，所述第一业务类型为该当前业务消息的业务类型，所述第二业务类型为该当前业务消息的依赖业务消息中包含的业务消息的业务类型；

第一节点通过以下方式保存当前业务消息：

第一节点按照接收的当前业务消息包含的第一业务类型，将接收到的每一个当前业务消息添加到所述保存的业务消息中，其中，业务类型相同的业务消 息保存在同一张数据表中；

步骤303：第一节点判断所述当前业务消息是否具有依赖业务消息；若判断结果为否，则结束；若判断结果为是，则执行步骤304；

由于在所述当前业务消息不具有依赖业务消息时，不需要对该当前业务消息进行处理，因此，这里结束对该当前业务消息处理过程结束，可以针对下一时刻的当前业务消息执行上述步骤301。

沿用步骤301中的例子，假设所述当前业务消息接收到的是交易付款消息，则本步骤303中就结束处理。

具体可以根据当前业务消息是否携带第二业务标识来判断该当前业务消息是否具有依赖业务消息；若携带了第二业务标识，则确定具有依赖业务消息，反之，则确定不具有依赖业务消息；在各业务消息的业务类型不相同且该当前业务消息携带了第一业务类型时，也可以根据第一业务类型来判断该当前业务消息是否具有依赖业务消息；若第一业务类型与具有依赖业务消息的业务类型相同，则确定具有依赖业务消息，反之，则确定不具有依赖业务消息；

例如：在当前业务消息为交易付款消息时，其携带的业务标识除了交易标识外，没有携带其他业务标识，因此，可以判断其不具体有依赖业务消息；在当前业务消息为仓储作业订单创建消息时，其携带的业务标识除了仓储作业订单标识外，还有交易标识和物流订单标识，因此，其具有依赖业务消息。

步骤304：第一节点判断保存的业务消息中，是否存在该当前业务消息的依赖业务消息；若判断结果为否，则执行步骤305；若判断结果为是，则执行步骤306；

具体的，在当前业务消息携带有至少一个第二业务标识时，可以针对每一第二业务标识，查找保存的业务消息中是否存在第一业务标识与该第二业务标识相同的业务消息；若均查找到，则确定保存的业务消息中，存在该当前业务消息的依赖业务消息，反之，则确定保存的业务消息中，不存在该当前业务消息的依赖业务消息。

在接收的当前业务消息中携带有至少一个第二业务类型，且第一节点将当前业务消息按照携带的第一业务类型添加到所述保存的业务消息中时，此时的查找，还可以为针对当前业务消息携带的每一个第二业务标识，先查找对应的业务类型与该第二业务标识对应的第二业务类型相同的数据表；然后再在查找到的数据表中，查找包含的第一业务标识与该第二业务标识相同的业务消息。

步骤305：针对该当前业务消息创建等待任务；之后执行步骤307；

其中，该当前业务消息的依赖业务消息包括对该当前业务消息执行关联业务处理时，需要使用的业务消息；

这里对该当前业务消息执行关联业务处理时需要使用的业务消息的个数是根据实际需要来决定的，可以为一个，也可以为多个；

这里创建的所述等待任务用于等待该当前业务消息的依赖业务消息。

在本步骤305中，还可以为等待任务设置创建时间参数，以方便后续按创建时间的先后顺序对等待任务进行处理。

较佳的，在当前业务消息中携带有第一业务标识，或者携带有第一业务标识和至少一个第二业务标识时，第一节点可以通过以下两个步骤针对该当前业务消息创建等待任务：

第一步：第一节点将该当前业务消息的第二业务标识以及第一业务标识作为该等待任务的等待条件参数；

在当前业务消息中还携带有第一业务类型，或者第一业务类型和至少一个第二业务类型时，所述第一步可具体包括：第一节点将该当前业务消息携带的第一业务标识、第一业务类型、第二业务标识和相对应的第二业务类型作为该等待任务的等待条件参数；

第二步：利用该等待条件参数，针对该当前业务消息创建等待任务。

这里将第一业务标识、第一业务类型、第二业务标识和第二业务类型作为等待条件参数，目的是为了便于后续查找等待任务等待的依赖业务消息。

此外，在创建等待任务时还可以将当前业务消息的扩展数据作为等待任务 的扩展数据参数，方便后续在接收到等待的依赖业务数据后，将当前业务消息中的业务数据、依赖业务消息中的业务数据以及所述扩展业务数据进行关联业务处理，以满足不同的业务需求。

步骤306：对该当前业务消息与其依赖的业务消息进行关联业务处理。

这里将当前业务消息与其依赖的业务消息进行关联业务处理本质是根据业务需要，将当前业务消息中的业务数据与其依赖的业务消息中的业务数据进行关联业务处理。

这里进行关联业务处理时，也可以加入该当前业务消息的扩展业务数据，将当前业务消息中的业务数据、依赖业务消息中的业务数据以及所述扩展业务数据进行关联业务处理，以满足不同的业务需求。

例如，针对图1中所示，假设是将仓储订单消息，与交易付款消息和物流订单消息进行关联业务处理，则此时可以是根据交易付款消息中的交易金额、交易商品的类型、交易商品的重量来计算物流订单是否需要收取快递费，以及收取快递费的金额，并由此来决定仓储作业订单的作业优先级。

当然，这里仅是一个举例，具体进行何种以及如何进行关联业务处理是根据业务本身和实际需求进行的，不同的业务和不同的需求进行关联业务处理的种类和方法并不一定相同，由于这并不是本申请所要解决的技术问题，因此，这里对此不再进行详述。

步骤307：第一节点将创建的所述等待任务写入到等待任务队列中，并指示至少一个第二节点从等待任务队列中获取等待任务，以及针对获取的每一等待任务，若确定第一节点保存的业务消息中存在该等待任务等待的依赖业务消息，则利用该依赖业务消息，对创建该等待任务时所针对的当前业务消息执行关联业务处理。

这里的等待任务队列可以是第一节点创建的，也可以是其他节点(例如分布式定时任务节点)创建的。

这里第一节点指示第二节点来对等待任务进行处理，此时的处理是对等待 任务进行异步处理，第一节点继续进行当前业务消息的接收及保存，随着时间的推移，等待任务等待的依赖业务消息就可能会被第一节点接收到并添加到保存的业务消息中，此时，在第二节点针对该等待任务进行处理时，就能从当前或最新保存的业务消息中，查询到依赖业务消息，进而对创建该等待任务时所针对业务消息和查询到的依赖业务消息进行关联业务处理。

实施例二

如图4所示，其为本申请实施例二提供的业务消息处理方法的流程图，包括以下步骤：

步骤401：第二节点从等待任务队列中获取等待任务；之后执行步骤402；

其中，每个等待任务是第一节点接收到当前业务消息，并确定保存的业务消息中，不存在该当前业务消息的依赖业务消息时，针对该当前业务消息创建的等待任务；

该当前业务消息的依赖业务消息包括对该当前业务消息执行关联业务处理时，需要使用的业务消息；

创建的所述等待任务用于等待该当前业务消息的依赖业务消息；

所述第一节点将接收到的每一个当前业务消息添加到所述保存的业务消息中；

关于等待任务的创建在实施例一中已经进行了详细的描述，这里不再赘述。

所述第二节点获取的等待任务，可以是第二节点从第一节点中主动获取等待任务，也可以是第二节点通过分布式定时任务节点定时从第一节点中获取的等待任务；

上述分布式定时任务节点可以对第一节点创建的等待任务队列定期进行扫描，每次从所述等待任务队列中取出一批等待任务，将取出的等待任务分发给多个第二节点。扫描的时间间隔可以根据业务系统的业务消息最大延迟时长 来确定，例如，将时间间隔设置为业务消息最大延时时长的设定倍数；针对电子商务系统而言，通常业务消息的延迟都在1秒之内，扫描的时间间隔可以设置为15秒。

这里的第二节点获取等待任务以及后续对等待任务进行处理的过程和第一节点接收当前业务消息以及后续执行的保存业务消息，创建等待任务等一系列处理过程，可以是相互独立的；第二节点和第一节点各自进行自身的处理过程，两者可以是同时进行的，也可以不是同时进行的；

步骤402：第二节点判断获取的等待任务中是否还有等待任务，若是，则执行步骤403；若否，则结束。

步骤403：第二节点从获取的等待任务中取出一个等待任务，之后执行步骤404；

在消息量大时，创建的等待任务较多，这里第二节点获取的等待任务的个数通常为多个，因此，需要从获取的等待任务中逐一取出每个等待任务，针对该取出的等待任务，执行步骤404至步骤406；

这里本次取出的等待任务通常是与上一次取出的等待任务不相同的等待任务，除非只剩下一个等待任务。

考虑到一条业务链上的各业务通常是顺次发生的，业务消息是按照其对应的业务的实际发生时间产生的，该业务消息的依赖业务消息也是按照其对应的业务的实际发生时间产生的，并且第一节点是为先到达的业务消息先创建等待任务，这就使得先创建的等待任务等待的依赖业务消息到达第一节点的时间往往，早于后创建的等待任务等待的依赖业务消息的到达第一节点的时间；为了尽快对等待任务进行处理，将等待任务等待的依赖业务消息与创建该等待任务时所针对的当前业务消息进行关联业务处理，需要对先创建的等待任务先进行处理，较佳的，所述等待任务具有创建时间参数；此时，本步骤303具体包括：

所述第二节点按照创建时间参数指示的创建时间由先到后的顺序，从获取的等待任务中取出一个等待任务。

步骤404：判断第一节点保存的业务消息中，是否存在取出的等待任务等待的依赖业务消息；若是，则执行步骤405；若否，则执行步骤406；

这里可以根据创建等待任务时设置的等待条件参数来判断第一节点保存的业务消息中，是否存在取出的等待任务等待的依赖业务消息。等待条件参数可被设置为依赖业务消息的业务标识及业务类型等信息。

在当前业务消息中携带有携带有第一业务标识和至少一个第二业务标识，创建的所述等待任务的等待条件参数包含该当前业务消息携带的第二业务标识时，在本步骤404中，第二节点具体可以通过以下两个步骤确定第一节点保存的业务消息中，是否存在该等待任务等待的依赖业务消息：

步骤1)：在第一节点保存的业务消息中，针对该等待任务的等待条件参数中包含的每一第二业务标识，查找包含的第一业务标识与该第二业务标识相同的业务消息；

步骤2)：若针对该等待任务的等待条件参数中包含的每一第二业务标识，均查找到包含的第一业务标识与该第二业务标识相同的业务消息，则确定保存的业务消息中存在该等待任务等待的依赖业务消息；反之，则确定保存的业务消息中不存在该等待任务等待的依赖业务消息。

较佳的，若当前业务消息中还携带有第一业务类型和第二业务类型，所述等待条件参数还包含该当前业务消息携带的第一业务类型和第二业务类型；所述保存的业务消息中，携带的第一业务类型相同的业务消息保存在同一张数据表中时，上述步骤1)，具体包括：

查找对应的业务类型与该等待任务的等待条件参数中包含的第二业务类型相同的数据表；

在查找到的数据表中，查找包含的第一业务标识与该等待任务的等待条件参数中包含的第二业务标识相同的业务消息。

步骤405：第二节点利用该依赖业务消息，对创建该等待任务时所针对的当前业务消息执行关联业务处理，并删除该等待任务；之后跳转至步骤402；

步骤406：第二节点将该等待任务存入获取的等待任务中；之后跳转至步骤403。

由于这里第一节点保存的业务消息不存在取出的等待任务的依赖业务消息，因此，需要将该等待任务重新放回获得的等待任务中，获取的等待任务中必定还有等待任务，因此，不用跳转至步骤402，而是跳转至步骤403。

在上述实施例一及实施例二的方案中，所述当前业务消息可以但不限定为物流消息。这里的物流消息是广义的，包括与物流相关的各种信息，这些信息将物流过程中的订货、收货、库存管理、发货、配送及回收等职能有机地联系在一起，使整个物流活动能够顺利进行。例如，图1中所示的供应链单据中心系统中产生的交易付款消息、物流订单创建消息和仓储作业订单创建消息均与物流相关，均可称为物流信息。

在当前业务消息为物流消息时，本实施例一的方案即为应用在物流业务场景下的物流消息处理方法，在接收到一个物流消息时，由于在该物流消息的依赖业务消息没有到达时，不是对该物流消息进行回滚及重试操作，而是创建等待任务，等待该物流消息的依赖业务消息的到达之后，再对该物流消息执行关联业务处理，因此，当物流消息量大且不能保证按照设定顺序到达时，大量的物流消息不会被重试，物流消息不会因重试而在消息中间件服务器中的大量堆积，提高了消息中间件服务器的稳定性。

例如，针对图1中所示的供应链单据中心系统，根据本申请实施例一的方案，假设在t1时刻，第一节点接收到了业务标识为A_3的仓储作业订单创建消息，该仓储作业订单创建消息中携带有其依赖的交易付款消息和物流订单创建消息的物流业务标识为A_2和A_1，此时，确定保存的物流消息中没有存储业务标识为A_2和A_1的物流消息，保存接收的该业务标识为A_3的仓储作业订单创建消息，并创建用于等待业务标识为A_2和A_1的物流消息的等待任务T1，写入等待任务队列；

在t2时刻，第一节点接收到业务标识为B_2的物流订单创建消息并保存 到物流消息中；

在t3时刻，第一节点接收到业务标识为B_1的交易付款消息并保存到物流消息中；

在t4时刻，第一节点接收到业务标识为A_2的物流订单创建消息并保存到物流消息中；

在t5时刻，第一节点接收到业务标识为A_1的物流订单创建消息并保存到物流消息中；

在t6时刻，第一节点接收到业务标识为B_3的仓储作业订单创建消息，该仓储作业订单创建消息还携带了业务标识B_1和B_2，此时，第一节点确定保存的物流消息中存在业务标识B_1和B_2的交易付款消息和物流订单创建消息；利用该业务标识B_1和B_2的交易付款消息和物流订单创建消息，对业务标识为B_3的仓储作业订单创建消息执行业务关联处理；

与此同时，在t6时刻，第二节点从等待任务队列中获取T1任务并进行处理，查找物流消息中存在业务标识为A_2和A_1的交易付款消息和物流订单创建消息；利用查找到的消息，对业务标识为A_3的仓储作业订单创建消息执行业务关联处理；

由上述过程可见，相对于背景技术中的按照实际业务发生顺序执行关联处理的业务消息处理方案，t1、t2、t4、t6时刻接收到的业务消息均没有向相应的消息中间件服务器发送处理失败稍后重试消息，相应的消息中间件服务器既不需要接收该失败重试消息，也不需要将该消息继续保存(以便稍后的重新发送)，这就使得大量的消息不会被堆积在相应的消息中间件服务器中，消息中间件服务器只需要执行转发任务即可，进而提高了消息中间件服务器的稳定性。

实施例三

与实施例一相对应的，本申请实施例三提供一种业务消息处理装置，该业 务消息处理装置具有上述实施例一中的第一节点的功能，如图5所示，其为本申请实施例三提供的业务消息处理装置的结构示意图，包括：接收模块51、保存模块52、创建模块53和写入模块54；其中：

接收模块51，用于接收当前业务消息；

保存模块52，用于保存接收的当前业务消息；

创建模块53，用于若确定保存的业务消息中不存在该当前业务消息的依赖业务消息，则针对该当前业务消息创建等待任务，其中，该当前业务消息的依赖业务消息包括对该当前业务消息执行关联业务处理时，需要使用的业务消息，创建的所述等待任务用于等待该当前业务消息的依赖业务消息；

写入模块54，用于将创建的所述等待任务写入到等待任务队列中，并指示至少一个第二节点从等待任务队列中获取等待任务，以及针对获取的每一等待任务，若确定第一节点保存的业务消息中存在该等待任务等待的依赖业务消息，则利用该依赖业务消息，对创建该等待任务时所针对的当前业务消息执行关联业务处理。

较佳的，所述当前业务消息为物流消息。

较佳的，当前业务消息中携带有第一业务标识，或者携带有第一业务标识和至少一个第二业务标识，其中，第一业务标识为该当前业务消息的业务标识，第二业务标识为该当前业务消息的依赖业务消息中包含的业务消息的业务标识；

所述创建模块53，具体用于将该当前业务消息携带的第二业务标识作为该等待任务的等待条件参数；利用该等待条件参数，针对该当前业务消息创建等待任务。

较佳的，当前业务消息中还携带有第一业务类型，或者第一业务类型和至少一个第二业务类型，其中，第一业务类型为该当前业务消息的业务类型，第二业务类型为该当前业务消息的依赖业务消息中包含的业务消息的业务类型；

所述保存模块52，具体用于按照携带的第一业务类型，将接收到的每一个 当前业务消息添加到所述保存的业务消息中，其中，业务类型相同的业务消息保存在同一张数据表中；

所述创建模块53，具体用于将该当前业务消息携带的第二业务标识和携带的第二业务类型作为该等待任务的等待条件参数。

由于该业务消息处理装置所解决问题的原理与前述实施例一及实施例二的业务消息处理方法相似，因此该业务消息处理装置的实施可以参见前述实施例一及实施例二的业务消息处理方法的实施，重复之处不再赘述。

实施例四

与实施例二相对应的，本申请实施例四提供一种业务消息处理装置，该业务消息处理装置具有上述实施例二中的第二节点的功能，如图6所示，其为本申请实施例四提供的业务消息处理装置的结构示意图，包括：，包括：获取模块61和执行模块62；其中：

获取模块61，用于从等待任务队列中获取等待任务，其中，每个等待任务是第一节点接收到当前业务消息，并确定保存的业务消息中，不存在该当前业务消息的依赖业务消息时，针对该当前业务消息创建的等待任务，该当前业务消息的依赖业务消息包括对该当前业务消息执行关联业务处理时，需要使用的业务消息，创建的所述等待任务用于等待该当前业务消息的依赖业务消息，所述第一节点将接收到的每一个当前业务消息添加到所述保存的业务消息中；

执行模块62，用于针对获取的每一等待任务，执行以下操作：若确定第一节点保存的业务消息中，存在该等待任务等待的依赖业务消息，则利用该依赖业务消息，对创建该等待任务时所针对的当前业务消息执行关联业务处理，并删除该等待任务。

较佳的，所述当前业务消息为物流消息。

较佳的，所述等待任务具有创建时间参数；

所述执行模块62，具体用于按照创建时间参数指示的创建时间由先到后的 顺序，针对获取的每一等待任务，执行所述操作。

较佳的，当前业务消息中携带有第一业务标识和至少一个第二业务标识，其中，第一业务标识为该当前业务消息的业务标识，第二业务标识为该当前业务消息的依赖业务消息中包含的业务消息的业务标识；创建的所述等待任务具有等待条件参数，该等待条件参数包含该当前业务消息携带的第二业务标识；

所述执行模块62，具体用于在第一节点保存的业务消息中，针对该等待任务的等待条件参数中包含的每一第二业务标识，查找携带的第一业务标识与该第二业务标识相同的业务消息；若针对每一第二业务标识，均查找到包含的第一业务标识与该第二业务标识相同的业务消息，则确定保存的业务消息中存在该等待任务等待的依赖业务消息。

较佳的，当前业务消息中还携带有第一业务类型和至少一个第二业务类型，其中，第一业务类型为该当前业务消息的业务类型，第二业务类型为该当前业务消息的依赖业务消息中包含的业务消息的业务类型；所述至少一个第二业务标识与所述至少一个第二业务类型相对应，所述等待条件参数还包含该当前业务消息携带的第二业务类型；所述保存的业务消息中，携带的第一业务类型相同的业务消息保存在同一张数据表中；

所述执行模块62，具体用于在第一节点保存的业务消息中，针对该等待任务的等待条件参数中包含的每一第二业务标识，执行以下操作：查找对应的业务类型与该第二业务标识对应的第二业务类型相同的数据表；在查找到的数据表中，查找包含的第一业务标识与该第二业务标识相同的业务消息。

由于该业务消息处理装置所解决问题的原理与前述实施例一及实施例二的业务消息处理方法相似，因此该业务消息处理装置的实施可以参见前述实施例一及实施例二的业务消息处理方法的实施，重复之处不再赘述。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明实施例可以通过硬件实现，也可以借助软件加必要的通用硬件平台的方式实现。基于这样的理解，本发明实施例的技术方案可以以软件产品的形式体现出 来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

本领域技术人员可以理解附图只是一个优选实施例的示意图，附图中的模块或流程并不一定是实施本发明所必须的。

本领域技术人员可以理解实施例中终端中的模块可以按照实施例描述进行分布于实施例的终端中，也可以进行相应变化位于不同于本实施例的一个或多个终端中。上述实施例的模块可以合并为一个模块，也可以进一步拆分成多个子模块。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。