运单状态更新的处理方法、装置、设备及存储介质

技术领域

本申请涉及互联网技术领域，尤其涉及一种运单状态更新的处理方法、装置、设备及存储介质。

背景技术

随着电子商务的不断发展，网络购物呈爆发式增长，大大促进了电子商务物流服务业尤其是快递服务业的发展，使其成为物品流通的重要渠道。为了提供优质的网上购物体验，电商平台需要协同各物流企业，不断完善物流数据更新方案。

目前，物流数据更新方案中，物流管理平台接收物流人员上报的运单操作请求，例如请求更新运单状态为已发货，通过执行该运单操作请求关联的操作任务，在该请求的所有操作任务均执行成功后，向电商平台返回物流更新数据。

上述物流数据更新方案存在长时间占用处理线程的问题，在一定程度上限制了平台处理请求的能力。

发明内容

本申请实施例提供一种运单状态更新的处理方法、装置、设备及存储介质，提高运单状态更新的速度。

本申请实施例的第一方面提供一种运单状态更新的处理方法，包括：

获取内存队列中待处理的第一运单操作请求，所述第一运单操作请求用于请求更新第一运单的状态；

执行所述第一运单操作请求关联的至少一个操作任务，若所述至少一个操作任务中有未完成的操作任务，暂停执行所述第一运单操作请求中未完成的操作任务，继续执行所述内存队列中位于所述第一运单操作请求之后的第二运单操作请求，所述第二运单操作请求用于请求更新第二运单的状态，所述第一运单和所述第二运单不同。

在本申请第一方面的一个可选实施例中，所述暂停执行所述第一运单操作请求中未完成的操作任务，包括：

若所述第一运单操作请求中未完成的操作任务的执行次数小于预设值，将所述第一运单操作请求置于所述内存队列的尾部，等待下一次执行。

在本申请第一方面的一个可选实施例中，所述暂停执行所述第一运单操作请求中未完成的操作任务，包括：

若所述第一运单操作请求中未完成的操作任务的执行次数大于或等于预设值，将所述第一运单操作请求剔除所述内存队列，并记录剔除时刻。

在本申请第一方面的一个可选实施例中，所述方法还包括：

获取预设时段内被剔除的所有运单操作请求，按照剔除顺序依次将被剔除的运单操作请求加入所述内存队列，等待再次执行。

在本申请第一方面的一个可选实施例中，所述执行所述第一运单操作请求关联的至少一个操作任务，包括：

并行执行所述第一运单操作请求关联的第一操作任务和第二操作任务；

所述第一操作任务用于发送与所述第一运单关联的订单跟踪消息；

所述第二操作任务用于更新所述第一运单的状态。

在本申请第一方面的一个可选实施例中，所述执行所述第一运单操作请求关联的至少一个操作任务，包括：

确定与所述第一运单操作请求关联的第三运单操作请求中的所有操作任务是否均执行成功，若均执行成功，执行所述第一运单操作请求关联的至少一个操作任务。

在本申请第一方面的一个可选实施例中，若所述第三运单操作请求中的所有操作任务中有未完成的操作任务，暂停执行所述第一运单操作请求，直至所述第三运单操作请求中的所有操作任务均执行成功。

在本申请第一方面的一个可选实施例中，所述方法还包括：

当所述第一运单操作请求关联的所有操作任务均执行成功时，生成运单更新记录，所述运单更新记录用于指示已完成所述第一运单的状态更新。

在本申请第一方面的一个可选实施例中，所述第一运单或所述第二运单的状态包括以下任意一项：

运单接单、等待妥投、妥投、拒收或拒收到库。

本申请实施例的第二方面提供一种运单状态更新的处理装置，包括：

获取模块，用于获取内存队列中待处理的第一运单操作请求，所述第一运单操作请求用于请求更新第一运单的状态；

处理模块，用于执行所述第一运单操作请求关联的至少一个操作任务，若所述至少一个操作任务中有未完成的操作任务，暂停执行所述第一运单操作请求中未完成的操作任务，继续执行所述内存队列中位于所述第一运单操作请求之后的第二运单操作请求，所述第二运单操作请求用于请求更新第二运单的状态，所述第一运单和所述第二运单不同。

在本申请第二方面的一个可选实施例中，所述处理模块，用于：

若所述第一运单操作请求中未完成的操作任务的执行次数小于预设值，将所述第一运单操作请求置于所述内存队列的尾部，等待下一次执行。

在本申请第二方面的一个可选实施例中，所述处理模块，用于：

若所述第一运单操作请求中未完成的操作任务的执行次数大于或等于预设值，将所述第一运单操作请求剔除所述内存队列，并记录剔除时刻。

在本申请第二方面的一个可选实施例中，所述获取模块，用于获取预设时段内被剔除的所有运单操作请求，所述处理模块，用于按照剔除顺序依次将被剔除的运单操作请求加入所述内存队列，等待再次执行。

在本申请第二方面的一个可选实施例中，所述处理模块，用于：

并行执行所述第一运单操作请求关联的第一操作任务和第二操作任务；

所述第一操作任务用于发送与所述第一运单关联的订单跟踪消息；

所述第二操作任务用于更新所述第一运单的状态。

在本申请第二方面的一个可选实施例中，所述处理模块，用于：

确定与所述第一运单操作请求关联的第三运单操作请求中的所有操作任务是否均执行成功，若均执行成功，执行所述第一运单操作请求关联的至少一个操作任务。

在本申请第二方面的一个可选实施例中，所述处理模块，用于：

若所述第三运单操作请求中的所有操作任务中有未完成的操作任务，暂停执行所述第一运单操作请求，直至所述第三运单操作请求中的所有操作任务均执行成功。

在本申请第二方面的一个可选实施例中，所述处理模块，用于：

当所述第一运单操作请求关联的所有操作任务均执行成功时，生成运单更新记录，所述运单更新记录用于指示已完成所述第一运单的状态更新。

在本申请第二方面的一个可选实施例中，所述第一运单或所述第二运单的状态包括以下任意一项：

运单接单、等待妥投、妥投、拒收或拒收到库。

本申请实施例的第三方面提供一种电子设备，包括：

存储器；

处理器；以及

计算机程序；

其中，所述计算机程序存储在所述存储器中，并被配置为由所述处理器执行以实现如第一方面中任一项所述的方法。

本申请实施例的第四方面提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行以实现如第一方面中任一项所述的方法。

本申请实施例的第五方面提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现第一方面中任一项所述的方法。

本申请实施例提供一种运单状态更新的处理方法、装置、设备及存储介质。该方法包括：通过获取内存队列中待处理的第一运单操作请求，该第一运单操作请求用于请求更新第一运单的状态，执行第一运单操作请求关联的至少一个操作任务，若该至少一个操作任务中有未完成的操作任务，暂停执行第一运单操作操作请求，继续执行内存队列中位于第一运单操作请求之后的第二运单操作请求，第二运单操作请求用于请求更新第二运单的状态，其中第一运单和第二运单不同。上述方案可避免异常运单操作请求关联的操作任务长时间占用线程，提升运单状态更新的速度，提高接单效率。

附图说明

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

图1为本申请实施例提供的运单状态更新的处理方法的场景示意图；

图2为本申请实施例提供的运单状态更新的处理方法的流程示意图；

图3为本申请实施例提供的运单状态的示意图；

图4为本申请实施例提供的内存队列与处理线程的示意图；

图5为本申请实施例提供的运单状态更新的处理装置的结构示意图；

图6为本申请实施例提供的电子设备的硬件结构图。

通过上述附图，已示出本申请明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围，而是通过参考特定实施例为本领域技术人员说明本申请的概念。

具体实施方式

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

本申请实施例的说明书、权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述之外的顺序实施。

应当理解，本文中使用的术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

在本申请实施例的描述中，术语“对应”可表示两者之间具有直接对应或间接对应的关系，也可以表示两者之间具有关联关系，也可以是指示与被指示、配置与被配置等关系。

首先对本申请实施例涉及到的相关术语进行简要说明。

业务条线，是指电商平台对接的内外部运力，例如电商平台自营快递、第三方快递等。各个运力内部存在较大差异，例如是否有自研能力、配送环节细分粒度不同等。

妥投，是指运输公司根据寄件人指定的地址和收件人按照规定要求将物品投交无误。多数情况下，物品是在收发室或快速驿站被签收，物品并没有实际交到收件人手中就提前自行结束了妥投业务。

运单操作(运单动作)，是指物流人员或库管人员通过客户端向物流管理平台上报物流数据的操作，例如库管人员扫描包裹二维码，该操作指示包裹已出库。

在介绍本申请提供的运单状态更新的处理方法之前，首先对该处理方法的应用场景进行简要介绍。

图1为本申请实施例提供的运单状态更新的处理方法的场景示意图。如图1所示，该场景包括客户端11、服务端12以及物流管理端13。其中客户端11分别与服务端12和物流管理端13通信连接，服务端12与物流管理端13通信连接。

客户端11可以是物流人员A、库管人员B或订单用户C的客户端，服务端12可以是电商平台，物流管理端13可以是物流管理平台。物流管理平台可以为内外部运力提供物流业务的流程管理，还可以向电商平台更新物流业务数据，例如更新运单状态等。

作为一种示例，库管人员B可通过客户端登录物流管理平台更新订单出入库数据，例如入库时间、出口时间等。物流人员A可通过客户端登录物流管理平台更新订单物品运输数据，例如当前运输位置、运输开始时刻等。订单用户C可通过客户端登录电商平台查看订单的物流数据，例如物流轨迹、达到驿站的预计时间等。

可选的，可将物流管理端13的流程管理功能集成于服务端12，服务端12可以为内外部运力提供物流业务的流程管理，还可以提供物流更新和查询服务。

目前物流业务的数据处理方案中，物流管理平台接收某一运单操作请求，例如物流人员或库管人员上报的运单操作请求，基于不同业务条线流程，执行与该运单操作请求对应的业务条件流程，执行完毕后返回结果。

上述数据处理方案存在如下问题：

第一，同一运单操作不同业务条线的流程不统一，各个业务耦合度高，修改任意业务条线将影响其他业务条线。

第二，串行执行业务流程耗时过长，处理失败风险较高，失败时无完善系统补偿方案，需要人工介入运维，人力成本较高。

第三，长时间占用接单线程，串行执行，在一定程度上限制了系统处理请求的能力。

随着物流管理平台业务日益复杂，业务流程也更加精细。传统的物流业务的数据处理方案已无法满足爆发式增长的数据量。因此，亟需对物流业务的数据处理方案进行优化。

为了解决上述问题，本申请实施例提出一种运单状态更新的处理方法，通过预配置运单操作请求与任务的关联关系，对不同业务条线的运单状态更新过程作规范化处理，实现业务解耦。通过设置任务执行次数阈值，及时调取异常任务，减少卡单，提高新业务接入时效，提高处理速度。通过多线程并发执行方式，进一步提高业务处理的数量和速度。

下面通过具体实施例对本申请实施例提供的技术方案进行详细说明。需要说明的是，本申请实施例提供的技术方案可以包括以下内容中的部分或全部，下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。

图2为本申请实施例提供的运单状态更新的处理方法的流程示意图。本实施例的运单状态更新的处理方法可应用于上述物流管理端，即对应物流管理平台，或者，应用于任意可执行该方法的设备或装置，如上述服务端，对此本实施例不作具体限定。

如图2所示，本实施例的运单状态更新的处理方法包括如下步骤：

步骤201、获取内存队列中待处理的第一运单操作请求，第一运单操作请求用于请求更新第一运单的状态。

本实施例中，第一运单操作请求可以是库管人员通过客户端触发的请求，也可以是物流人员通过客户端触发的请求，对此本申请实施例不作具体限定。

第一运单操作请求用于请求更新第一运单的状态，第一运单的状态包括以下任意一项：运单接单、等待妥投、妥投、拒收或拒收到库。

图3为本申请实施例提供的运单状态的示意图。如图3所示，根据运单的流转流程，运单状态依次为运单接单、等待妥投、妥投/拒收，拒收之后还包括拒收到库。

运单接单，是指操作订单出库，是配送环节的起点。库管人员操作出库时，可触发第一运单操作请求，该第一运单操作请求用于请求更新第一运单的状态为运单接单。

等待妥投，是指订单已发货，快递配送中。物流人员操作开始运输时，可触发第一运单操作请求，该第一运单操作请求用于请求更新第一运单的状态为等待妥投。

妥投，是指订单物品已送达，客户签收，配送结束。物流人员操作物品已签收时，触发第一运单操作请求，该第一运单操作请求用于请求更新第一运单的状态为妥投。

拒收，是指订单物品已送达，客户拒绝签收，订单物品需要退回。物流人员操作物品拒收时，触发第一运单操作请求，该第一运单操作请求用于请求更新第一运单的状态为拒收。

拒收到库，是指订单物品被用户拒收后，订单物品被退回至仓库或接收站点。库管人员操作订单物品重新入库时，触发第一运单操作请求，该第一运单操作请求用于请求更新第一运单的状态为拒收到库。

步骤202、执行第一运单操作请求关联的至少一个操作任务。

基于物流人员或库管人员的操作内容触发不同类型的第一运单操作请求，不同类型的第一运单操作请求关联的操作任务可能相同或不同。下面对不同类型的第一运单操作请求关联的操作任务进行详细说明。

在一种可能的实施方式中，若第一运单操作请求用于请求更新第一运单的状态为运单接单，第一运单操作请求关联的操作任务包括：任务A1、任务A2和任务A3。任务A1用于呼叫外部运力，即呼叫运输公司。任务A2用于发送订单跟踪信息，如订单物品已出库。任务A3用于更新订单状态为已出库待发货。

在一种可能的实施方式中，若第一运单操作请求用于请求更新第一运单的状态为等待妥投，第一运单操作请求关联的操作任务包括：任务B1和任务B2。任务B1用于发送订单跟踪信息，如由某运输公司配送，运单号为xxx。任务B2用于更新订单状态为已发货。

在一种可能的实施方式中，若第一运单操作请求用于请求更新第一运单的状态为妥投，第一运单操作请求关联的操作任务包括：任务C1和任务C2。任务C1用于发送订单跟踪信息，如客户已签收订单物品。任务C2用于更新订单状态为已妥投。

在一种可能的实施方式中，若第一运单操作请求用于请求更新第一运单的状态为拒收，第一运单操作请求关联的操作任务包括：任务D1和任务D2。任务D1用于发送订单跟踪信息，如客户已拒收订单物品。任务D2用于更新订单状态为已拒收。

在一种可能的实施方式中，若第一运单操作请求用于请求更新第一运单的状态为拒收到库，第一运单操作请求关联的操作任务包括：任务E1、任务E2和任务E3。任务E1用于发送订单跟踪信息，如库管人员接收拒收到库的订单物品。任务E2用于更新订单状态为拒收到库。任务E3用于触发退款操作。

步骤203、若至少一个操作任务中有未完成的操作任务，暂停执行第一运单操作请求。

第一运单只要有一项未完成的操作任务，则暂停执行第一运单操作请求，暂停执行具体包括如下两种可能的实施方式：

在一种可能的实施方式中，若第一运单操作请求中未完成的操作任务的执行次数小于预设值，将第一运单操作请求置于内存队列的尾部，等待下一次执行。

可选的，若第一运单操作请求中未完成的操作任务的执行次数小于预设值，将该第一运单操作请求标记为更新失败，同时将第一运单操作请求置于内存队列的尾部，等待下一次执行。

示例性的，若第一运单操作请求用于请求更新第一运单的状态为等待妥投，执行第一运单操作请求关联的两个操作任务，即上文的任务B1和任务B2，若任务B1执行成功，任务B2执行失败的次数小于预设值(例如3次)，则将该第一运单操作请求标记为更新失败，并将该第一运单操作请求置于内存队列的尾部，等待下一次执行，下一次执行只需要执行任务B2即可。

在一种可能的实施方式中，若第一运单操作请求中未完成的操作任务的执行次数大于或等于预设值，将第一运单操作请求剔除内存队列，并记录剔除时刻。

可选的，若第一运单操作请求中未完成的操作任务的执行次数大于或等于预设值，将该第一运单操作请求标记为更新失败，同时将第一运单操作请求剔除内存队列，并记录剔除时刻。

示例性的，若第一运单操作请求用于请求更新第一运单的状态为妥投，执行第一运单操作请求关联的两个操作任务，即上文的任务C1和任务C2，若任务C1执行成功，任务C2执行失败的次数大于或等于预设值(例如3次)，则将该第一运单操作请求标记为更新从内存队列中剔除，并记录剔除时刻，等待再次加入内存队列。

步骤204、继续执行内存队列中位于第一运单操作请求之后的第二运单操作请求，第二运单操作请求用于请求更新第二运单的状态。

本实施例中，第一运单和第二运单不同。第一运单和第二运单不同包括运单对应的订单物品不同，或者运单对应的订单用户不同。

例如，第一运单对应订单1，第二运单对应订单2，订单1和订单2来自不同用户，订单1和订单2中的物品可能相同或不同。又例如，第一运单和第二运单来自同一订单，该订单物品拆分为两个运单，即第一运单和第二运单对应的订单物品不同。

与第一运单操作请求类似，第二运单操作请求关联至少一个操作任务，执行第二运单操作请求即执行第二运单操作请求关联的至少一个操作任务，操作任务的具体内容与第二运单操作请求请求更新的第二运单的状态有关，可参见上文对第一运单操作请求的操作任务的示例，此处不再赘述。

第二运单的状态同样包括以下任意一项：

运单接单、等待妥投、妥投、拒收或拒收到库。

需要说明的是，对于同一类型的运单操作请求，例如请求更新运单的状态为订单接单，通过预配置运单操作请求与任务的关联关系，使得不同业务条线的运单状态更新过程一致，使得业务数据处理更加规范化。另外，可通过修改预配置的上述关联关系，实现对不同业务条线的运单状态更新过程的统一更新，降低运维人员的工作量，提高对物流管理功能的更新效率。

本申请实施例示出的运单状态更新的处理方法，通过获取内存队列中待处理的第一运单操作请求，该第一运单操作请求用于请求更新第一运单的状态，执行第一运单操作请求关联的至少一个操作任务，若该至少一个操作任务中有未完成的操作任务，暂停执行第一运单操作操作请求，继续执行内存队列中位于第一运单操作请求之后的第二运单操作请求，第二运单操作请求用于请求更新第二运单的状态，其中第一运单和第二运单不同。上述方案可避免异常运单操作请求关联的操作任务长时间占用线程，提升运单状态更新的速度，提高接单效率。

可选的，在一些实施例中，执行第一运单操作请求关联的至少一个操作任务，包括：并行执行第一运单操作请求关联的第一操作任务和第二操作任务。其中，第一操作任务用于发送与第一运单关联的订单跟踪消息；第二操作任务用于更新第一运单的状态。

可选的，为了进一步提升接单能力，可扩展更多线程，实现同时处理内存队列中多个运单操作请求关联的操作任务。下面通过一个具体示例对多线程并行处理过程进行说明。

示例性的，图4为本申请实施例提供的内存队列与处理线程的示意图。如图4所示，内存队列包括运单操作请求1至5，其中，运单操作请求1关联任务a、b、c，运单操作请求2关联任务d和e，运单操作请求3关联任务f，运单操作请求4关联任务g和h，运单操作请求5关联任务i、j、k。假设并行处理的线程最大数量为5，那么可同时执行的任务数为5，可同时执行内存队列中运单操作请求1和2关联的操作任务，即任务a至e。

在上述几个实施例的基础上，若第一运单操作请求中未完成的操作任务的执行次数大于或等于预设值，将第一运单操作请求剔除内存队列，并记录剔除时刻。可选的，在一些实施例中，第一运单操作请求被剔除后等待补漏。

补漏过程包括：获取预设时段内(例如30分钟之前，或者，一天之内)被剔除的所有运单操作请求，按照剔除顺序依次将被剔除的运单操作请求加入所述内存队列，等待再次执行。其中，再次执行被剔除的运单操作请求是指再次执行被剔除的运单操作请求关联的未完成的操作任务。

可选的，在一些实施例中，当物流管理端重启时，可通过上述补漏过程将重启之前内存队列中等待执行的运单操作请求再次加入内存队列中。其中内存队列中等待执行的运单操作请求包括：第一次执行的运单操作请求以及标记为更新失败的运单操作请求(即等待重复执行的运单操作请求)。

示例性的，基于图3示例，假设运单操作请求1和运单操作请求3在预设时段内均被剔除内存队列，按照剔除时刻的先后顺序，依次将运单操作请求1和3加入内存队列的尾部，等待再次执行。假设运单操作请求1中未完成的任务为任务3，运单操作请求3只有一个任务6，任务6为未完成任务。那么只需要将任务3和任务6依次加入并行处理线程中的空闲线程，再次执行任务3和6，完成补漏。

通过上述补漏过程，在不影响系统正常接单的情况下，可批量对未完成运单状态更新的请求进行处理，提高系统综合处理能力。

需要说明的是，补漏的周期比重复执行异常请求(不剔除队列，直接添加到队尾)的周期要长，通常设置为一天。当然，可根据实际应用需求灵活设置补漏的周期，对此本申请实施例不作具体限定。

可选的，在一些实施例中，执行第一运单操作请求关联的至少一个操作任务之前，还可以包括如下步骤：确定与第一运单操作请求关联的第三运单操作请求中的所有操作任务是否均执行成功。

在一种可能的实施方式中，若与第一运单操作请求关联的第三运单操作请求中的所有操作任务均执行成功，执行第一运单操作请求关联的至少一个操作任务。

在一种可能的实施方式中，若第三运单操作请求中的所有操作任务中有未完成的操作任务，暂停执行第一运单操作请求，直至第三运单操作请求中的所有操作任务均执行成功。

本实施例中，第一运单操作请求与第三运单操作请求请求更新的运单均为第一运单，且第三运单操作请求早于第一运单操作请求。

示例性的，第三运单操作请求是库管人员通过客户端触发的，用于请求更新第一运单的状态为运单接单。第三运单请求是物流人员通过客户端触发的，用于请求更新第一运单的状态为等待妥投。若第三运单操作请求还未更新成功，则需要等待第三运单操作请求关联的操作任务全部执行完毕后，再执行第一运单操作请求关联的操作任务。上述方案可确保第一运单的各个运单操作请求有序执行，确保第一运单的物流信息的完整性，即确保第一运单的物流信息中每个环节数据的成功更新。

可选的，在一些实施例中，当第一运单操作请求关联的所有操作任务均执行成功时，生成运单更新记录，运单更新记录用于指示已完成第一运单的状态更新。可将运单更新记录存储在数据库中，以便用于确定同一运单的后续运单操作请求是否立刻执行，可参见上一个实施例。

上文描述了本申请实施例提供的运单状态更新的处理方法，下面将描述本申请实施例提供的运单状态更新的处理装置。

本申请实施例可以根据上述方法实施例对运单状态更新的处理装置进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以使用硬件的形式实现，也可以使用软件功能模块的形式实现。

需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。下面以使用对应各个功能划分各个功能模块为例进行说明。

图5为本申请实施例提供的运单状态更新的处理装置的结构示意图。如图5所示，本实施例提供的运单状态更新的处理装置，包括：获取模块301和处理模块302。

获取模块301，用于获取内存队列中待处理的第一运单操作请求，所述第一运单操作请求用于请求更新第一运单的状态；

处理模块302，用于执行所述第一运单操作请求关联的至少一个操作任务，若所述至少一个操作任务中有未完成的操作任务，暂停执行所述第一运单操作请求中未完成的操作任务，继续执行所述内存队列中位于所述第一运单操作请求之后的第二运单操作请求，所述第二运单操作请求用于请求更新第二运单的状态，所述第一运单和所述第二运单不同。

在本实施例的一个可选实施例中，所述处理模块302，用于：

若所述第一运单操作请求中未完成的操作任务的执行次数小于预设值，将所述第一运单操作请求置于所述内存队列的尾部，等待下一次执行。

在本实施例的一个可选实施例中，所述处理模块302，用于：

若所述第一运单操作请求中未完成的操作任务的执行次数大于或等于预设值，将所述第一运单操作请求剔除所述内存队列，并记录剔除时刻。

在本实施例的一个可选实施例中，所述获取模块301，用于获取预设时段内被剔除的所有运单操作请求，所述处理模块302，用于按照剔除顺序依次将被剔除的运单操作请求加入所述内存队列，等待再次执行。

在本实施例的一个可选实施例中，所述处理模块302，用于：

并行执行所述第一运单操作请求关联的第一操作任务和第二操作任务；

所述第一操作任务用于发送与所述第一运单关联的订单跟踪消息；

所述第二操作任务用于更新所述第一运单的状态。

在本实施例的一个可选实施例中，所述处理模块302，用于：

确定与所述第一运单操作请求关联的第三运单操作请求中的所有操作任务是否均执行成功，若均执行成功，执行所述第一运单操作请求关联的至少一个操作任务。

在本实施例的一个可选实施例中，所述处理模块302，用于：

若所述第三运单操作请求中的所有操作任务中有未完成的操作任务，暂停执行所述第一运单操作请求，直至所述第三运单操作请求中的所有操作任务均执行成功。

在本实施例的一个可选实施例中，所述处理模块302，用于：

当所述第一运单操作请求关联的所有操作任务均执行成功时，生成运单更新记录，所述运单更新记录用于指示已完成所述第一运单的状态更新。

在本实施例的一个可选实施例中，所述第一运单或所述第二运单的状态包括以下任意一项：

运单接单、等待妥投、妥投、拒收或拒收到库。

本实施例提供的运单状态更新的处理装置，可以执行上述任一方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。

图6为本申请实施例提供的电子设备的硬件结构图，如图6所示，本实施例提供的电子设备400，包括：

存储器401；

处理器402；以及

计算机程序；

其中，计算机程序存储在存储器401中，并被配置为由处理器402执行以实现上述任一方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。

可选的，存储器401既可以是独立的，也可以跟处理器402集成在一起。当存储器401是独立于处理器402之外的器件时，电子设备400还包括：总线403，用于连接存储器401和处理器402。

本申请实施例还提供一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器402执行以实现如前述任一方法实施例的技术方案。

本申请实施例提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现如前述任一方法实施例的技术方案。

本申请实施例还提供了一种芯片，包括：处理模块与通信接口，该处理模块能执行前述任一方法实施例的技术方案。

进一步地，该芯片还包括存储模块(如，存储器)，存储模块用于存储指令，处理模块用于执行存储模块存储的指令，并且对存储模块中存储的指令的执行使得处理模块执行前述任一方法实施例的技术方案。

应理解，上述处理器可以是中央处理单元(英文：Central Processing Unit，简称：CPU)，还可以是其他通用处理器、数字信号处理器(英文：Digital Signal Processor，简称：DSP)、专用集成电路(英文：Application Specific Integrated Circuit，简称：ASIC)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合发明所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

存储器可能包含高速RAM存储器，也可能还包括非易失性存储NVM，例如至少一个磁盘存储器，还可以为U盘、移动硬盘、只读存储器、磁盘或光盘等。

总线可以是工业标准体系结构(Industry Standard Architecture，ISA)总线、外部设备互连(Peripheral Component，PCI)总线或扩展工业标准体系结构(ExtendedIndustry Standard Architecture，EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，本申请附图中的总线并不限定仅有一根总线或一种类型的总线。

上述存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。存储介质可以是通用或专用计算机能够存取的任何可用介质。

一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于专用集成电路(Application Specific Integrated Circuits，简称：ASIC)中。当然，处理器和存储介质也可以作为分立组件存在于电子设备中。

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