一种物流订单数据处理方法及装置与流程

本申请涉及计算机技术领域，尤其涉及一种物流订单数据处理方法及装置。

背景技术：

物流订单及物流订单的订单状态是用于记录一个真实的物流包裹从创建到完结这一过程的数据。物流包裹从创建到完结可能经历发货人、仓库、物流公司、揽件员、派件员中间的层层流转，最终辗转送达收货人手上，这些数据均可通过记录的物流订单及物流订单状态来记录。

通常每一条物流订单及该物流订单的订单状态数据是通过物流平台中的数据库来记录的。下面通过图1对一个包裹经历发货人、仓库、物流公司、揽件员、派件员中间的层层流转过程及相应地对物流平台中的物流订单的操作进行说明，图1中包括以下步骤：

步骤1：发货人在物流平台中创建一条物流订单；

步骤2：发货人进行第一次选择，之后转向步骤31或执行步骤32；

步骤31：发货人针对该创建的物流订单在物流平台中选择发货，物流平台将该物流订单下发给物流公司，之后转向步骤4；

步骤32：发货人不发货，发货人主动将在物流平台中创建的物流订单关闭；

步骤4：物流公司进行第一次选择，之后转向步骤51或步骤52；

步骤51：物流公司同意接单且揽收，之后执行步骤6；

这里，物流公司揽收之后将会把包裹送达收货人；

步骤52：物流公司拒绝接单或者同意接单但拒绝揽收，之后转向步骤10；

步骤6：收货人第二次选择，之后转向步骤71或步骤72；

步骤71：收货人拒签，之后转向步骤8；

步骤72：收货人签收，之后转向步骤8；

步骤8：物流公司第二次选择，之后转向步骤91或转向步骤92；

步骤91：物流公司向物流平台回传拒签。

步骤92：物流公司向物流平台回传签收。

步骤10：发货人第三次选择，之后转向步骤111或步骤112；

步骤111：发货人在物流平台中关闭当前物流订单，不发货；

步骤112：发货人在物流平台中关闭当前物流订单，然后重新创建新的物流订单；之后转向步骤2。

上述过程，在理想情况下，每一条物流订单最终都会走向关闭，签收或者拒签这三种状态。但事实情况并非如此，例如以下情况：

1、发货人创建物流订单之后一直没有选择发货，也没有选择主动关闭交易，如图1中的①；

2、发货人选择发货之后物流公司一直没有选择接单和揽收也没有选择拒绝接单和拒绝揽收，如图1中的②；

3、物流公司拒绝接单或者拒绝揽收之后，发货人又没有选择再次发货或者主动关闭物流订单，如图1中的③；

4、收货人收到货之后，物流公司既没有回传签收也没有回传拒签如图1中的④。

在上述4种情况下，现有的物流订单处理方案是，如果一直没有发起者主动推动这条物流订单，那么让这条该物流订单将永远存在下去，永远不会达到完结状态(关闭、签收、拒签)。

现有的物流订单数据处理方案只能让物流订单的订单状态在理想的情况下自动走向完结状态。这依靠发货人、物流公司的自觉以及物流公司系统的稳定性等等大量不可靠因素。当这些不可靠因素发生在每天上千万，甚至上亿级别物流订单上时，每天产生的这类僵尸订单的数量将是非常庞大的。这类僵尸物流订单无法进入完结状态，也就无法被删除或者移动到历史物流订单数据 库，只能堆积在有限的当前物流订单数据库中。一方面，将会大量占用物流平台的存储服务器上额外的存储空间；另一方面，随着时间的推移，堆积在当前物流订单数据库中的没有使用价值的僵尸物流订单数量的会越来越庞大，这将导致在利用物流平台中的当前物流订单数据库，对具有使用价值的物流订单的进行查询时，查询速度变得十分缓慢。

技术实现要素：

本申请实施例提供一种物流订单数据处理方法及装置，用以解决僵尸物流订单占用存储服务器上额外的存储空间和导致查询速度变慢的问题。

基于上述问题，本申请实施例提供的一种物流订单数据处理方法，包括：

监听物流订单数据库在数据发生变更时广播的数据变更消息，所述数据变更消息中包含物流订单的标识和变更信息；

对监听到的数据变更消息进行过滤，得到包含变更后的订单状态不为完结状态中的任一状态信息的数据变更消息；所述变更信息包含订单类型和变更后的订单状态，所述订单类型包括关联外部业务订单和不关联外部业务订单，所述完结状态包括：关闭、签收和拒收；

针对过滤后得到的数据变更消息中包含的每一物流订单的标识所表示的物流订单，在设定时长后，执行以下操作：

查询该物流订单在物流订单数据库中的当前订单状态；

若该物流订单的变更后的订单状态与当前订单状态一致，则确定该物流订单的订单类型；

若该物流订单的订单类型为关联外部业务订单，则进一步确定该物流订单关联的外部业务订单的当前订单状态；

根据确定的外部业务订单的当前订单状态，对物流订单数据库中该物流订单的订单状态进行更改，所述更改使得该物流订单的订单状态能走向完结状态中的一种。

一种物流订单数据处理装置，包括：

监听单元，用于监听物流订单数据库在数据发生变更时广播的数据变更消息，所述数据变更消息中包含物流订单的标识和变更信息；

过滤单元，用于对监听到的数据变更消息进行过滤，得到包含变更后的订单状态不为完结状态中的任一状态信息的数据变更消息；所述变更信息包含订单类型和变更后的订单状态，所述订单类型包括关联外部业务订单和不关联外部业务订单，所述完结状态包括：关闭、签收和拒收；

更改单元，用于针对过滤后得到的数据变更消息中包含的每一物流订单的标识所表示的物流订单，在设定时长后，执行以下操作：查询该物流订单在物流订单数据库中的当前订单状态；若该物流订单的变更后的订单状态与当前订单状态一致，则确定该物流订单的订单类型；若该物流订单的订单类型为关联外部业务订单，则进一步确定该物流订单关联的外部业务订单的当前订单状态；根据确定的外部业务订单的当前订单状态，对物流订单数据库中该物流订单的订单状态进行更改，所述更改使得该物流订单的订单状态能走向完结状态中的一种。

在本申请实施例的方案中，首先过滤出了变更后的订单状态不为完结状态中的任一状态的数据变更消息，其次，对过滤出的数据变更消息中的每一物流订单的标识所表示的物流订单进行了定时任务处理，在设定时长后，进行该物流订单的变更后的订单状态与当前订单状态进行对比，订单状态一致时，说明该物流订单在所述设定时长内状态没有发生变化，进行进一步确定该物流订单关联的外部业务订单的当前订单状态，之后根据确定的外部业务订单的当前订单状态，对物流订单数据库中该物流订单的订单状态进行更改，实现了对订单状态不为完结状态，订单类型为关联外部业务的物流订单，且设定时长内订单状态没有发生变化的物流订单的订单状态的更改，并且所述更改使得该物流订单的订单状态能走向完结状态中的一种，由于该物流订单的订单状态处于完结状态，因此，可将该物流订单删除或移动到历史物流订单处理器，减少了存储 物流订单数据库的服务器上额外的存储空间的占用，并且减少了堆积在当前物流订单数据中的没有使用价值的僵尸物流订单的数量，进而提高了当前物流订单数据库中对具有使用价值的物流订单的进行查询的速度。

附图说明

图1为本申请中对包裹的层层流转过程及相应地对物流平台中的物流订单的操作的示意图；

图2为本申请实施例一提供的物流订单数据处理方法的流程图；

图3为本申请实施例二提供的物流订单数据处理方法的流程图之一；

图4为本申请实施例二提供的物流订单数据处理方法的流程图之二；

图5为本申请实施例二提供的物流订单数据处理方法的流程图之三；

图6为本申请实施例三提供的物流订单数据处理装置的结构示意图。

具体实施方式

为了解决僵尸物流订单占用存储服务器上额外的存储空间和导致当前物流订单数据库的查询速度变慢的问题，本申请实施例提供一种物流订单数据处理方法及装置。

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

为了清楚地理解本申请实施例的方案，这里首先对物流订单的订单类型进行说明：

现有的物流订单按照是否与其它业务系统产生的业务订单有关联，分为关联外部业务订单的物流订单和不关联外部业务订单的物流订单。其中，外部业务订单指的是其他业务系统的订单，该其它业务系统的订单需要依靠物流订单进行发货，也即需要与物流订单进行关联。例如，网上商城的交易订单就可以 称为是外部业务订单，因为交易订单上一般只有交易信息，如交易金额、交易时间、交易商品等，但不会包含复杂的物流发货信息，所以需要依靠物流订单进行发货。利用所述交易订单创建的物流订单就可称为关联外部业务订单的物流订单。对于一个作为消费者的用户通过物流平台寄送一个包裹时创建的物流订单，对该物流平台使用的功能就仅仅是联系物流公司、查看物流详情等。这种情况就是不关联外部业务订单的物流订单。

针对关联外部业务订单和不关联外部业务订单这两种不同订单类型的物流订单，均包括发货地址、收货地址、物流公司信息以及运单号等信息，关联外部业务订单的物流订单中还可以包括外部交易订单的标识，或者外部交易订单的标识和外部交易信息；这里的外部交易信息可以包括交易金额、交易商品和交易数量等信息。

下面结合附图，用具体实施例对本申请提供的方法及装置进行详细描述。

实施例一

如图2所示，其为本申请实施例一提供的一种物流订单数据处理方法的流程图，包括以下步骤：

步骤201：监听物流订单数据库在数据发生变更时广播的数据变更消息，之后执行步骤202；

在数据驱动业务流转的系统架构中，每一次数据的变更都会往外部发送一条数据变更消息。而承载物流订单的系统就是此种类型的系统。承载物流订单的系统在数据发生变更时，系统中的物流订单数据库就广播数据变更消息，所述数据变更消息中包含物流订单的标识和变更信息。这里的变更信息也即为变更的内容。可以包含变更后的内容，还可以包含变更前的内容，通常，还可以包括变更时间。

用户每次通过承载物流订单的系统中的物流平台发货都会产生一条物流订单，这条物流订单能完整的表达货物从哪里发出，发往哪里，中间经过了哪 些人对这条物流订单做了什么。这条物流订单从创建开始，每发生一个变化，物流订单数据库都会将其变化的数据通过数据变更消息的形式广播出来；针对这些广播出的数据变更消息，不同的业务系统监听自己感兴趣的消息。例如，有些业务系统专门监听包含物流订单创建的数据变更消息，有些业务系统专门监听包含运单号变化的数据变更消息，有些业务系统专门监听包含收货地址修改的数据变更消息等等，而本申请实施例中监听的是包含订单状态变更的数据变更消息。

步骤202：对监听到的数据变更消息进行过滤，得到包含变更后的订单状态不为完结状态中的任一状态信息的数据变更消息，之后执行步骤203；

物流订单的订单状态包括：完结状态和非完结状态，其中，完结状态又包括：关闭、签收和拒收；非完结状态包括：等待物流公司接单、等待物流公司揽收、物流公司接单、物流公司揽收、等待发货人发货、等待发货人重新发货等等。在物流订单的订单状态为完结状态时，该条物流订单走向完结，可以被移入历史物流订单数据库或者删除。

下面对接单和揽收进行说明：用户通过网络创建物流订单，将用户的要求快递东西的消息发送给物流公司，物流公司可以根据自己的实际情况，如揽派范围，人员情况等，选择是否接收个物流订单，选择做这个物流订单就是接单；揽收是在线上选择接单之后，派遣快递员去揽收包裹。当快递员拿到这个包裹后，将拿到包裹的这条消息上传到物流平台，这条消息就是揽收。

所述变更信息包含订单类型、变更前的订单状态和变更后的订单状态，所述订单类型包括关联外部业务订单和不关联外部业务订单；

由于本申请需要处理的是处于非完结状态的物流订单，因此，需要对监听到的数据变更消息进行过滤，过滤出包含变更后的订单状态的数据变更消息，且该过滤出的数据变更消息中包含的变更后的订单状态为非完结状态中的订单状态，也可以说过滤出的数据变更消息中包含的变更后的订单状态不为完结状态中的任一状态，之后针对该过滤出的数据变更消息进行后续处理。

优选的，所述数据变更消息中还包括变更类型；所述变更类型包括：订单状态变更、运单号变更、收货地址变更、新订单创建等等；

此时，步骤202中，进行过滤时，可以先根据变更类型对监听到的数据变更消息进行过滤，判断监听到的各条数据变更消息中包含的变更类型是否为订单状态变更；若是，则保留此条数据变更消息，若否，则丢弃该条数据变更消息；之后，针对保留的各条数据变更消息进行再次过滤，判断数据变更消息中包含的变更后的订单状态是否为完结状态中的任一种，若是，则丢弃此条变更消息，若否，则保留此条数据变更消息；此时，再次过滤后得到的即为变更后的订单状态不为完结状态中的任一状态的数据变更消息，也即变更类型为订单状态变更、且变更后的订单状态不为完结状态中的任一状态的数据变更消息。

步骤203：针对过滤后得到的数据变更消息中包含的每一物流订单的标识所表示的物流订单，在设定时长后，执行以下述步骤204至步骤212；

所述设定时长可以是国内普通快递从发货地址到投递到收货地址平均需要的时长，也可以是根据经验值设定的时长，还可以是根据统计的每个不同的订单状态在物流订单从创建状态到完结状态这一生命周期中流转到下一个状态的时间，对统计得到的各个时间的统计值，例如，对各个统计得到的时间进行加权平均，或者取各个统计得到的时间的最大值等等；

这里在设定时长后执行下述步骤204至步骤206，目的是为了等待物流订单的改变，在设定时长后，有些物流订单的当前状态已经发生了改变，而有些物流订单的当前状态并没有发生改变，这些当前状态已经发生了改变的物流订单，该物流订单从目前的情况看是正在走向下一个订单状态或者正在走向完结状态，目前必定不是僵尸物流订单。

步骤204：查询该物流订单在物流订单数据库中的当前订单状态，之后执行步骤205；

由于过滤后得到的数据变更消息中包含物流订单的标识，因此，利用根据该物流订单的标识，在物流订单数据库中查询该物流订单的标识所表示的物流 订单的当前订单状态。

步骤205：判断该物流订单的变更后的订单状态与当前订单状态是否一致，若判断结果为是，则执行步骤206；若判断结果为否，则执行步骤207；

这里，若该物流订单的变更后的订单状态与当前订单状态相同，则确定该物流订单的变更后的订单状态与当前订单状态一致；若该物流订单的变更后的订单状态与当前订单状态不相同，则确定该物流订单的变更后的订单状态与当前订单状态不一致。

步骤206：判断该物流订单的订单类型是否为关联外部业务订单；若是，则执行步骤208；若否，则执行步骤209；

由于关联外部业务订单类型的物流订单，其订单状态的改变是依靠其关联的外部业务订单的订单状态；而不关联外部业务订单类型的物流订单，其订单状态的改变是由自身决定的，因此，本步骤206需要对物流订单的订单类型进行区分，以便于对不同订单类型的物流订单分别进行处理。

步骤207：结束；

这里，由于该物流订单的变更后的订单状态与当前订单状态不一致，说明物流订单当前必定不为僵尸订单，因此，不需要进行处理。

步骤208：确定该物流订单关联的外部业务订单的当前订单状态，之后执行步骤210；

步骤209：根据该物流订单的处于变更后的订单状态的时长，判断该物流订单是否超时；若超时，则执行步骤211；若没有超时，则执行步骤212；

具体的，可以查询物流订单数据库中该物流订单的当前订单状态，若当前订单状态与变更后的物流订单的订单状态一致，则可利用当前时间与包含该物流订单的数据变更消息中包含的变更时间之差相减，即得到该物流订单的处于变更后的订单状态的时长，然后将该得到的时长与设定的超时时长进行比较，大于设定的超时时长时，则确定为超时，否则，确定为未超时。可以对设定与各订单状态对应的超时时长。

步骤210：根据确定的外部业务订单的当前订单状态，对物流订单数据库中该物流订单的订单状态进行更改，所述更改使得该物流订单的订单状态能走向完结状态中的一种；

步骤211：将物流订单数据库中该物流订单的订单状态更改为关闭。

步骤212：等待设定时长，之后跳转至步骤204。

通过本申请实施例一的方案实现了对订单状态不为完结状态，订单类型为关联外部业务的物流订单，且设定时长内订单状态没有发生变化的物流订单的订单状态的更改，并且所述更改使得该物流订单的订单状态能走向完结状态中的一种，由于该物流订单的订单状态处于完结状态，因此，可将该物流订单删除或移动到历史物流订单处理器，并且对减少了存储物流订单数据库的服务器上额外的存储空间的占用，并且进一步实现了对订单状态不为完结状态，订单类型为不关联外部业务的物流订单，且设定时长内订单状态没有发生变化的物流订单的订单状态进行了关闭或者进行了重新进行超时判断，订单状态减少了堆积在当前物流订单数据中的没有使用价值的僵尸物流订单的数量，进而提高了当前物流订单数据库中对具有使用价值的物流订单的进行查询的速度。此外，还可以对本申请实施例一的方案进行优化，以便进一步减少僵尸物流订单，下面，通过实施例二的方案进行描述。

实施例二

如图3所示，其为本申请实施例一提供的一种物流订单数据处理方法的流程图，包括以下步骤：

步骤301：监听物流订单数据库在数据发生变更时广播的数据变更消息，之后执行步骤302；

步骤302：对监听到的数据变更消息进行过滤，得到包含变更后的订单状态不为完结状态中的任一状态信息的数据变更消息，之后执行步骤303；

上述步骤301至步骤302的具体实现细节与实施例一中的步骤201至步骤 202的具体实现细节相同，这里不再赘述。

步骤303：判断过滤后得到的数据变更消息中，包含的物流订单的标识所表示的物流订单的变更后的订单状态，是否为拒绝接单和拒绝揽收两种订单状态中的任一种；若是，则执行步骤304；若否，则执行步骤305；

步骤304：查询与该物流订单具有关联关系的最新创建的物流订单的标识，并将该物流订单的变更后的订单状态作为该最新创建的物流订单的变更后的订单状态，之后执行步骤305；

其中，可以通过以下第一步至第三步确定与该物流订单具有关联关系的最新创建的物流订单的标识：

第一步：确定变更后的订单状态为拒绝接单或者拒绝揽收状态的数据变更消息中的物流订单的标识；

第二步：利用确定的物流订单的标识查询物流订单数据库，该物流订单数据库中记录物流订单的标识和该物流订单的标识所表示的物流订单被关闭后重新创建的物流订单的标识之间的关联关系；

其中，该关联关系可以通过业务标识来实现；由于同一个业务的标识下，只有一个正常状态的物流订单，其他都处于被关闭/取消状态，因此可以根据当前消息体中的物流订单的标识，找到业务的标识，根据业务的标识找到重新创建的物流订单的标识；

第三步：从该物流订单数据库中查询该确定的物流订单的标识相关联的重新创建的物流订单的标识；

上述步骤301至步骤304可以理解为物流订单数据处理中的采集需要要处理的物流订单数据阶段。

步骤305：针对过滤后得到的数据变更消息中包含的每一物流订单的标识所表示的物流订单中，订单状态不为拒绝接单和拒绝揽收两种订单状态中的任一种的物流订单，和查询出的所述最新创建的物流订单的标识所表示的物流订单，在设定时长后，执行以下步骤306至步骤317；

步骤306：查询该物流订单在物流订单数据库中的当前订单状态，之后执行步骤307；

步骤307：判断该物流订单的变更后的订单状态与当前订单状态是否一致，若判断结果为是，则执行步骤308；若判断结果为否，则执行步骤309；

步骤308：判断该物流订单的订单类型是否为关联外部业务订单；若是，则执行步骤310；若否，则执行步骤311；

步骤309：结束；

步骤310：确定该物流订单关联的外部业务订单的当前订单状态，之后执行步骤312；

步骤311：根据该物流订单的处于变更后的订单状态的时长，判断该物流订单是否超时；若超时，则执行步骤313；若没有超时，则执行步骤314；

步骤312：判断外部业务订单的订单状态是否为成功完结或关闭，若是，则执行步骤315；若否，则执行步骤314；

步骤313：判断该物流订单的变更后的订单状态是否为等待物流公司接单或等待物流公司揽收，若是，则执行步骤316，若否，则执行步骤317；

步骤314：等待设定时长，之后跳转至步骤306。

步骤315：在外部业务订单的订单状态为成功完结时，将物流订单数据库中该物流订单的订单状态更改为签收；在外部业务订单的订单状态为关闭时，将物流订单数据库中该物流订单的订单状态更改为关闭；

步骤316：关闭该物流订单并重新创建一条物流订单，并设置该重新创建的一条物流订单的订单状态为等待发货人重新发货；

步骤317：将物流订单数据库中该物流订单的订单状态更改为关闭。

上述步骤305至步骤317，为需要等待设定时长后才执行的操作，可以将步骤305中待处理的每一物流订单的物流订单标识和变更后的订单状态这些数据看做是一个定时任务，相应地，可以将步骤305至步骤317理解为物流订单数据处理中的定时任务执行阶段。这时，上述步骤301至步骤304所描述的物 流订单数据采集过程也可以用图4来表达，上述步骤305至步骤317所描述的物流订单数据采集过程也可以用图5来表达，图4和图5中的目标状态即为变更后的订单状态，超时任务即为定时任务，Schedule为定时任务调度中心，由定时任务调度中心来执行图5中的过程。

在本申请实施例三的方案中，针对关联外部业务订单的物流订单，根据其关联的外部业务订单的订单状态对其订单状态进行修改，能够有效保证该物流订单的订单状态和其关联的外部业务订单的订单状态保持一致性，减少僵尸物流订单订单；针对没有关联外部业务订单的物流订单则能完全保证其状态走向终结，完全解决僵尸物流订单。

实施例三

基于同一发明构思，本申请实施例三还提供了一种物流订单数据处理装置，由于该装置所解决问题的原理与前述的物流订单数据处理方法相似，因此该装置的实施可以参见前述方法的实施，重复之处不再赘述。

如图6所示，其为本申请实施例三提供的物流订单数据处理装置的结构示意图，包括：监听单元61、过滤单元62和更改单元63；其中：

监听单元61，用于监听物流订单数据库在数据发生变更时广播的数据变更消息，所述数据变更消息中包含物流订单的标识和变更信息；

过滤单元62，用于对监听到的数据变更消息进行过滤，得到包含变更后的订单状态不为完结状态中的任一状态信息的数据变更消息；所述变更信息包含订单类型和变更后的订单状态，所述订单类型包括关联外部业务订单和不关联外部业务订单，所述完结状态包括：关闭、签收和拒收；

更改单元63，用于针对过滤后得到的数据变更消息中包含的每一物流订单的标识所表示的物流订单，在设定时长后，执行以下操作：查询该物流订单在物流订单数据库中的当前订单状态；若该物流订单的变更后的订单状态与当前订单状态一致，则确定该物流订单的订单类型；若该物流订单的订单类型为关 联外部业务订单，则进一步确定该物流订单关联的外部业务订单的当前订单状态；根据确定的外部业务订单的当前订单状态，对物流订单数据库中该物流订单的订单状态进行更改，所述更改使得该物流订单的订单状态能走向完结状态中的一种。

较佳的，所述更改单元63，还用于若该物流订单的订单类型为不关联外部业务订单，则根据该物流订单的处于变更后的订单状态的时长，确定该物流订单是否超时；若确定该物流订单超时，则将物流订单数据库中该物流订单的订单状态更改为关闭。

较佳的，所述更改单元63，具体用于若确定该物流订单超时，则进一步确定该物流订单的变更后的订单状态是否为等待物流公司接单或等待物流公司揽收；若确定该物流订单变更后的订单状态不为等待物流公司接单或等待物流公司揽收，则将物流订单数据库中该物流订单的订单状态更改为关闭。

较佳的，所述更改单元63，还用于若确定该物流订单变更后的订单状态为等待物流公司接单或等待物流公司揽收，则关闭该物流订单并重新创建一条物流订单，并设置该重新创建的一条物流订单的订单状态为等待发货人重新发货。

较佳的，所述更改单元63，具体用于在确定的外部业务订单的订单状态为成功完结时，将物流订单数据库中该物流订单的订单状态更改为签收；在确定的外部业务订单的订单状态为关闭时，将物流订单数据库中该物流订单的订单状态更改为关闭。

较佳的，所述更改单元63，还用于在确定的外部业务订单的订单状态为尚未完结时，在所述设定时长后，针对该物流订单执行所述操作。

较佳的，所述装置还包括：查询单元64，用于在过滤单元对监听到的数据变更消息进行过滤之后，变更单元针对过滤后得到的数据变更消息中包含的每一物流订单的标识所表示的物流订单，在设定时长后，执行所述操作之前，若确定过滤后得到的数据变更消息中，包含的物流订单的标识所表示的物流订单 的变更后的订单状态，为拒绝接单和拒绝揽收两种订单状态中的任一种，则查询与该物流订单具有关联关系的最新创建的物流订单的标识，并将该物流订单的变更后的订单状态，作为该最新创建的物流订单的变更后的订单状态；

所述更改单元63，具体用于针对过滤后得到的数据变更消息中，包含的物流订单的标识所表示的物流订单中，订单状态不为拒绝接单和拒绝揽收两种订单状态中的任一种的物流订单，和查询出的所述最新创建的物流订单的标识所表示的物流订单，在设定时长后，执行上述在设定时长后执行的操作。

在本申请实施例的方案中，首先通过监听数据变更消息来完成对僵尸物流订单的处理，无侵入性的设计保证原有的业务不会因为此次变更而受到影响。其次，通过监控每个物流订单的订单状态的变化，使用用定时任务来保证不关联外部业务订单的物流订单能够都走向完结(签收、拒签、关闭)，以及确保包含外部业务订单的物流订单，能够和其关联的外部业务订单的订单状态的一致性。

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

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

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

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

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