CN115563204A - 运单状态更新方法、装置、电子设备及存储介质 - Google Patents

Abstract

本申请提供一种运单状态更新方法、装置、电子设备及计算机可读存储介质。该运单状态更新方法包括：当分布式处理系统的redis数据库中记录的待维护运单存在新的路由操作信息时，在redis数据库中添加待维护运单的加锁记录，redis数据库存储有待维护运单的状态数据；当待维护运单的加锁记录添加成功时，基于新的路由操作信息以及redis数据库存储的待维护运单的当前状态信息，确定待维护运单的实际状态信息；基于实际状态信息，更新redis数据库存储的待维护运单的状态数据。本申请中可以避免物流运单数据高并发更新场景下容易出现数据覆盖情况而导致状态丢失的问题，提高了物流运单数据高并发更新场景下的数据更新准确性。

Description

运单状态更新方法、装置、电子设备及存储介质

技术领域

本申请涉及物流数据管理技术领域，具体涉及一种运单状态更新方法、装置、电子设备及计算机可读存储介质。

背景技术

随着人民生活水平不断地提高，线上购物成为了新的生活方式，线上购物的快速发展带动了物流行业的快速发展。为了满足物流行业的精细化运营，通常会记录运单的运单号、路由操作信息、运输状态等各类运单数据。

其中，路由操作信息、运输状态等各类运单数据在运单的整个运输过程中是会不断更新变化的，因此，需要不断地对物流运单数据库所记录运单的路由操作信息、运输状态等运单数据进行实时更新。但是，物流行业中存在大量的运单、且每个运单需要维护一个相对较长的周期，因此物流运单数据库所需记录或更新的运单数据量较大，并且存在高并发的情况。

然而，在高并发场景下，对同一运单的运单数据同时更新会出现数据覆盖的情况而导致状态丢失，进而导致运单数据更新不准确的问题。

发明内容

本申请提供一种运单状态更新方法、装置、电子设备及计算机可读存储介质，旨在解决物流运单数据高并发更新场景下容易出现数据覆盖情况而导致状态丢失，进而导致运单数据更新不准确的问题。

第一方面，本申请提供一种运单状态更新方法，所述方法包括：

当检测到预设分布式处理系统的redis数据库中记录的待维护运单存在新的路由操作信息时，在所述redis数据库中添加所述待维护运单的加锁记录，其中，所述redis数据库中存储有所述待维护运单的状态数据；

当所述待维护运单的加锁记录添加成功时，基于所述新的路由操作信息、以及所述redis数据库中存储的所述待维护运单的当前状态信息，确定所述待维护运单的实际状态信息；

基于所述实际状态信息，更新所述redis数据库中存储的待维护运单的状态数据。

在本申请一种可能的实现方式中，所述待维护运单的状态数据包括所述待维护运单的路由操作信息、所述待维护运单的运输状态、所述待维护运单的异常状态中至少一者。

在本申请一种可能的实现方式中，所述实际状态信息包括所述待维护运单的实际运输状态和实际异常状态，所述基于所述新的路由操作信息、以及所述redis数据库中存储的所述待维护运单的当前状态信息，确定所述待维护运单的实际状态信息，包括：

通过所述预设分布式处理系统的目标处理节点，从redis数据库中读取所述待维护运单的当前状态运输状态、所述待维护运单的当前异常状态；

基于所述新的路由操作信息以及所述当前运输状态，确定所述待维护运单的实际运输状态；

基于所述新的路由操作信息以及所述当前异常状态，确定所述待维护运单的实际异常状态。

在本申请一种可能的实现方式中，所述在所述redis数据库中添加所述待维护运单的加锁记录，包括：

通过所述目标处理节点，发起对所述待维护运单的加锁请求；

当所述待维护运单处于解锁状态时，基于所述加锁请求在所述redis数据库中添加所述待维护运单的加锁记录；

所述基于所述实际状态信息，更新所述redis数据库中存储的待维护运单的状态数据，包括：

通过所述目标处理节点，基于所述实际状态信息，更新所述redis数据库中存储的待维护运单的状态数据。

在本申请一种可能的实现方式中，所述方法还包括：

获取所述待维护运单存储在所述redis数据库中的存储时长；

当所述存储时长大于预设存储周期时长时，从所述redis数据库中删除所述待维护运单的状态数据。

在本申请一种可能的实现方式中，所述redis数据库用于存储所述待维护运单为目标对象的运单，所述当检测到预设分布式处理系统的redis数据库中记录的待维护运单存在新的路由操作信息时，在所述redis数据库中添加所述待维护运单的加锁记录，之前还包括：

获取所述目标对象的标识信息；

根据所述标识信息，从预设的物流数据记录库中获取所述目标对象的运单的路由操作信息集；

根据所述路由操作信息集，确定所述目标对象的运单的状态数据；

将所述目标对象的运单的状态数据存储至所述redis数据库。

在本申请一种可能的实现方式中，所述方法还包括：

按照预设的同步周期，将所述redis数据库所存储的待维护运单的状态数据同步至预设的展示平台；

通过所述展示平台，展示所述待维护运单的状态数据。

在本申请一种可能的实现方式中，所述基于所述实际状态信息，更新所述redis数据库中存储的待维护运单的状态数据，之后还包括：

在所述redis数据库中删除所述待维护运单的加锁记录。

第二方面，本申请提供一种运单状态更新装置，所述运单状态更新装置包括：

加锁单元，用于当检测到预设分布式处理系统的redis数据库中记录的待维护运单存在新的路由操作信息时，在所述redis数据库中添加所述待维护运单的加锁记录，其中，所述redis数据库中存储有所述待维护运单的状态数据；

确定单元，用于当所述待维护运单的加锁记录添加成功时，基于所述新的路由操作信息、以及所述redis数据库中存储的所述待维护运单的当前状态信息，确定所述待维护运单的实际状态信息；

更新单元，用于基于所述实际状态信息，更新所述redis数据库中存储的待维护运单的状态数据。

在本申请一种可能的实现方式中，所述待维护运单的状态数据包括所述待维护运单的路由操作信息、所述待维护运单的运输状态、所述待维护运单的异常状态中至少一者，所述实际状态信息包括所述待维护运单的实际运输状态和实际异常状态，所述确定单元具体用于：

通过所述预设分布式处理系统的目标处理节点，从redis数据库中读取所述待维护运单的当前状态运输状态、所述待维护运单的当前异常状态；

基于所述新的路由操作信息以及所述当前运输状态，确定所述待维护运单的实际运输状态；

基于所述新的路由操作信息以及所述当前异常状态，确定所述待维护运单的实际异常状态。

在本申请一种可能的实现方式中，所述加锁单元具体用于：

通过所述目标处理节点，发起对所述待维护运单的加锁请求；

当所述待维护运单处于解锁状态时，基于所述加锁请求在所述redis数据库中添加所述待维护运单的加锁记录；

在本申请一种可能的实现方式中，所述更新单元具体用于：

通过所述目标处理节点，基于所述实际状态信息，更新所述redis数据库中存储的待维护运单的状态数据。

在本申请一种可能的实现方式中，所述运单状态更新装置还包括周期管理单元，所述周期管理单元具体用于：

获取所述待维护运单存储在所述redis数据库中的存储时长；

当所述存储时长大于预设存储周期时长时，从所述redis数据库中删除所述待维护运单的状态数据。

在本申请一种可能的实现方式中，所述运单状态更新装置包括存储单元，所述redis数据库用于存储所述待维护运单为目标对象的运单，在所述当检测到预设分布式处理系统的redis数据库中记录的待维护运单存在新的路由操作信息时，在所述redis数据库中添加所述待维护运单的加锁记录的步骤之前，所述存储单元具体用于：

获取所述目标对象的标识信息；

根据所述标识信息，从预设的物流数据记录库中获取所述目标对象的运单的路由操作信息集；

根据所述路由操作信息集，确定所述目标对象的运单的状态数据；

将所述目标对象的运单的状态数据存储至所述redis数据库。

在本申请一种可能的实现方式中，所述运单状态更新装置包括同步单元，所述同步单元具体用于：

按照预设的同步周期，将所述redis数据库所存储的待维护运单的状态数据同步至预设的展示平台；

通过所述展示平台，展示所述待维护运单的状态数据。

在本申请一种可能的实现方式中，所述运单状态更新装置包括解锁单元，在所述基于所述实际状态信息，更新所述redis数据库中存储的待维护运单的状态数据的步骤之后，所述解锁单元具体用于：

在所述redis数据库中删除所述待维护运单的加锁记录。

第三方面，本申请还提供一种电子设备，所述电子设备包括处理器和存储器，所述存储器中存储有计算机程序，所述处理器调用所述存储器中的计算机程序时执行本申请提供的任一种运单状态更新方法中的步骤。

第四方面，本申请还提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器进行加载，以执行所述的运单状态更新方法中的步骤。

本申请当检测到redis数据库中记录的待维护运单存在新的路由操作信息时，在redis数据库中添加待维护运单的加锁记录；在待维护运单的加锁记录添加成功时，再对待维护运单的状态数据进行更新，避免了两个或以上的处理节点同时对待维护运单的状态数据进行更新，进而避免了同一运单的运单数据同时更新会出现数据覆盖的情况而导致状态丢失的问题。可见，一方面，由于可以避免物流运单数据高并发更新场景下容易出现数据覆盖情况而导致状态丢失的问题，进而避免运单数据更新不准确的问题，提高了物流运单数据高并发更新场景下的数据更新准确性。另一方面，由于是基于分布式处理系统对运单的状态数据进行更新，因此保证物流运单数据高并发更新需求，保证了运单的状态数据的更新实时性。

附图说明

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

图1是本申请实施例所提供的分布式处理系统的一种场景示意图；

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

图3是本申请实施例中提供的分布式加锁的一种流程示意图；

图4是本申请实施例中提供的运单数据写入redis数据库的一种过程示意图；

图5是本申请实施例中提供的运单状态更新装置的一个实施例结构示意图；

图6是本申请实施例中提供的电子设备的一个实施例结构示意图。

具体实施方式

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

在本申请实施例的描述中，需要理解的是，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个所述特征。在本申请实施例的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。

为了使本领域任何技术人员能够实现和使用本申请，给出了以下描述。在以下描述中，为了解释的目的而列出了细节。应当明白的是，本领域普通技术人员可以认识到，在不使用这些特定细节的情况下也可以实现本申请。在其它实例中，不会对公知的过程进行详细阐述，以避免不必要的细节使本申请实施例的描述变得晦涩。因此，本申请并非旨在限于所示的实施例，而是与符合本申请实施例所公开的原理和特征的最广范围相一致。

参见图1，图1是本申请实施例所提供的分布式处理系统的一种场景示意图。该分布式处理系统可以包括多个处理节点、以及用于存储待维护运单的状态数据的redis数据库。

其中，每个处理节点可以承载于本申请实施例的电子设备中，用于实现本申请实施例中的运单状态更新方法。例如，处理节点可以用于检测redis数据库中记录的待维护运单是否存在新的路由操作信息；当检测到预设分布式处理系统的redis数据库中记录的待维护运单存在新的路由操作信息时，检测所述待维护运单的加锁状态，其中，所述redis数据库中存储有所述待维护运单的状态数据；若所述待维护运单处于解锁状态时，在所述redis数据库中添加所述待维护运单的加锁记录；当所述待维护运单的加锁记录添加成功时，基于所述新的路由操作信息，更新所述redis数据库中存储的待维护运单的状态数据。

需要说明的是，图1所示的分布式处理系统的场景示意图仅仅是一个示例，本申请实施例描述的分布式处理系统以及场景是为了更加清楚的说明本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定，本领域普通技术人员可知，随着分布式处理系统的演变和新业务场景的出现，本发明实施例提供的技术方案对于类似的技术问题，同样适用。

本申请实施例运单状态更新方法的执行主体可以为本申请实施例提供的运单状态更新装置，或者集成了该运单状态更新装置的服务器设备、物理主机或者用户设备(UserEquipment，UE)等不同类型的电子设备，其中，运单状态更新装置可以采用硬件或者软件的方式实现，UE具体可以为智能手机、平板电脑、笔记本电脑、掌上电脑、台式电脑或者个人数字助理(Personal Digital Assistant，PDA)等终端设备。

该电子设备可以采用单独运行的工作方式，或者也可以采用设备集群的工作方式，通过应用本申请实施例提供的运单状态更新方法，避免了两个或以上的处理节点同时对待维护运单的状态数据进行更新，进而避免了同一运单的运单数据同时更新会出现数据覆盖的情况而导致状态丢失的问题。可见，一方面，由于可以避免物流运单数据高并发更新场景下容易出现数据覆盖情况而导致状态丢失的问题，进而避免运单数据更新不准确的问题，提高了物流运单数据高并发更新场景下的数据更新准确性。另一方面，由于是基于分布式处理系统对运单的状态数据进行更新，因此保证物流运单数据高并发更新需求，保证了运单的状态数据的更新实时性。

下面，开始介绍本申请实施例提供的运单状态更新方法，本申请实施例中以电子设备作为执行主体，为了简化与便于描述，后续方法实施例中将省略该执行主体，该运单状态更新方法包括：当检测到预设分布式处理系统的redis数据库中记录的待维护运单存在新的路由操作信息时，在所述redis数据库中添加所述待维护运单的加锁记录，其中，所述redis数据库中存储有所述待维护运单的状态数据；当所述待维护运单的加锁记录添加成功时，基于所述新的路由操作信息、以及所述redis数据库中存储的所述待维护运单的当前状态信息，确定所述待维护运单的实际状态信息；基于所述实际状态信息，更新所述redis数据库中存储的待维护运单的状态数据。

参照图2，图2是本申请实施例提供的运单状态更新方法的一种流程示意图。需要说明的是，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。该运单状态更新方法包括步骤201～203，其中：

201、当检测到预设分布式处理系统的redis数据库中记录的待维护运单存在新的路由操作信息时，在所述redis数据库中添加所述待维护运单的加锁记录。

其中，redis数据库中存储有待维护运单的状态数据。

其中，待维护运单是指存入redis数据库中的、需要实时更新维护的运单，比如，运输中的运单、已揽收但未派送至收件人的运单。进一步地，待维护运单还可以是特定对象(如月结客户)的、需要实时更新维护的运单，比如，月结客户运输中的运单。

路由操作信息是指运单运输过程中各个操作节点的记录信息，比如，揽收、装车、中转、卸车、派送操作节点的记录信息，各个操作节点的记录信息又可以进一步包括运单的操作节点的操作类型、操作时间、操作地点等。为了方便运单数据的记录与管理，一般来说，在每个操作节点工作人员会通过巴枪扫描运单生成对应的巴枪操作码并记录，每记录一个巴枪操作码表示对该运单执行了一个操作节点，本申请实施例中可以分别采用各个操作节点所记录的巴枪操作码、操作时间、操作地点等信息作为路由操作信息。此处，路由操作信息仅为举例，具体可以根据实际业务场景而设置更多或更少的记录信息，不以此为限制。

本申请实施例中，为了对运单进行实时更新，会将需要实时更新的运单的运单数据处理成一条状态数据存入redis数据库中进行维护。

其中，状态数据是运单的维护需求信息的记录值。比如，待维护运单的状态数据是待维护运单的路由操作信息、待维护运单的运输状态、待维护运单的异常状态、待维护运单的时效等。

redis数据库是具有极高的数据读写速度、支持数据的持久化的数据库。Redis作为基于内存、分布式、键值对(Key-Value)存储数据库，支持反查更新数据，适合高并发高吞吐的数据更新场景。本申请实施例中，考虑到物流场景中存在运单数据量大、且运单数据更新存在高并发情况的问题，采用redis数据库用于存储运单数据。

Redis基于内存运行并支持持久化，因此，可以满足物流场景中运单数据量大的需求。Redis采用key-value(键值对)的存储形式，可以通过Redis的分布式锁对运单加锁后进行运单数据的实时更新。

其中，预设分布式处理系统可以是基于flink分布式处理引擎的分布式处理系统，本申请实施例中，以基于flink分布式处理引擎的分布式处理系统进行说明。如图1所示，为了实现对运单数据的并发读写flink分布式处理引擎会启动多个处理节点，每个处理节点都可以从redis数据库读取待维护运单的状态数据，并基于待维护运单的状态数据和新的路由操作信息，更新待维护运单的状态数据，并将更新后的待维护运单的状态数据写回redis数据库中，从而实现待维护运单的状态数据的更新。

示例性地，步骤201具体可以包括：当预设分布式处理系统的目标处理节点接收到redis数据库中记录的待维护运单存在新的路由操作信息时，通过目标处理节点向redis数据库发起对待维护运单的加锁请求；若待维护运单已经存在其他处理节点的加锁记录时，对待维护运单的加锁请求将会失败；若待维护运单不存在其他处理节点的加锁记录时，即待维护运单处于解锁状态时，通过目标处理节点添加标记位的方式，基于加锁请求在redis数据库中添加待维护运单的加锁记录。

其中，目标处理节点是指预设分布式处理系统的各处理节点中，接收到待维护运单存在新的路由操作信息的处理节点。

为了方便理解，以一具体例子进行说明。如图3所示，图3是本申请实施例中提供的分布式加锁的一种流程示意图，加锁过程可以具体包括：

1、每来一条运单的运单路由操作信息，去redis数据库对该运单的运单号作为key，进行加锁。如果redis数据库中不存在该运单号作为key的记录，则加锁成功。如果redis数据库中存在该运单号作为key的数据，则加锁失败。

2、如果加锁成功，则继续执行后续步骤202处理；直至更新完毕时释放锁，将对应该运单号的key记录删除。如果加锁失败，说明有其他处理节点slot中正在针对该运单号的路由操作信息对redis数据库进行读写操作，则循环等待多次，重新加锁，直至加锁成功。

202、当所述待维护运单的加锁记录添加成功时，基于所述新的路由操作信息、以及所述redis数据库中存储的所述待维护运单的当前状态信息，确定所述待维护运单的实际状态信息；

其中，在对redis数据库中运单的运单数据进行更新之前，会将运单的运单数据写入redis数据库，示例性地，运单数据写入redis数据库的过程包括：

1)从预设的全网数据中，获取待维护运单的运单数据。

其中，待维护运单是需要存入redis数据库并实时更新的运单，例如，运输中的运单、已揽收但未派送至收件人的运单。

运单数据是指运单的记录信息，比如运单的运单号、收件人、寄件人、运输状态、路由操作信息、异常状态等信息。

2)根据待维护运单的运单数据、预设的维护需求信息，确定待维护运单的状态数据。

其中，预设的维护需求信息是根据实际业务场景需求而设置的所需维护的运单数据，比如，预设的维护需求信息可以是运单的重要节点路由操作信息(如揽收、发车、派送的记录信息)、运输状态、异常状态、时效等。预设的维护需求信息可以根据实际业务场景需求而设置，此处对预设的维护需求信息不作具体限制。

其中，运输状态是运单在整个运输过程中所处阶段的记录信息，比如，运输状态可以是“已揽收”、“运输中”、“待派送”、“派送中”等记录信息。运输状态可以根据待维护运单的路由操作信息、预设的状态翻转规则进行确定。其中，预设的状态翻转规则可以根据具体业务场景的需求而设置，此处对具体的状态翻转规则不作限制，比如，预设的状态翻转规则可以如下表1所示，根据表1中的状态翻转规则：当路由操作信息显示运单处于“揽收”操作节点时，运输状态为“揽收中”；当路由操作信息显示运单处于“装车”操作节点时，运输状态为“运输中”；当路由操作信息显示运单处于“卸车”操作节点时，运输状态为“待派送”；当路由操作信息显示运单处于“派送”操作节点时，运输状态为“派送中”。

表1

操作节点	运输状态
		揽收	已揽收
装车	运输中
		卸车	待派送
派送	派送中

异常状态是用于运单在处于异常状态的记录信息，比如，异常状态可以是运单的异常原因、异常操作地点、异常类别等记录信息。异常状态可以根据待维护运单的路由操作信息、运输状态等以及预设的异常判定规则进行确定。其中，预设的异常判定规则可以根据具体业务场景的需求而设置，此处对具体的异常判定规则不作限制，比如，预设的异常判定规则可以如下表2所示，根据表2中的异常判定规则：当运输状态为“揽收中”超过24h时，异常状态可以为“揽收滞留”；当运输状态为“待派送”超过12h时，异常状态可以为“派送异常”。

表2

运输状态	异常状态
		揽收中>24h	揽收滞留
待派送>12h	派送异常

类似地，可以针对其他维护需求信息、及其对应的数据处理规则，形成待维护运单的状态数据。

3)将待维护运单的运单号、状态数据关联存入redis数据库中。

至此，redis数据库中存储有待维护运单的状态数据。

此时，步骤202中，当待维护运单的加锁记录添加成功时，可以通过目标处理节点，从redis数据库中读取待维护运单的当前状态信息；并基于待维护运单的当前状态信息、新的路由操作信息，确定待维护运单的实际状态信息。

203、基于所述实际状态信息，更新所述redis数据库中存储的待维护运单的状态数据。

在一些实施例中，redis数据库中存储的待维护运单的状态信息可以是待维护运单的运输状态，待维护运单的实际状态信息是待维护运单的实际运输状态。此时步骤202具体可以包括如下步骤2021A～步骤2022A：

2021A、通过所述预设分布式处理系统的目标处理节点，从redis数据库中读取所述待维护运单的当前运输状态。

2022A、基于所述新的路由操作信息以及所述当前运输状态，确定所述待维护运单的实际运输状态。

步骤2022A中，可以通过预设的状态翻转规则、新的路由操作信息、以及redis数据库中存储的待维护运单的当前运输状态，确定待维护运单的实际运输状态。其中，待维护运单的实际运输状态的确定，可以参照运单数据写入redis数据库过程中所介绍的运输状态确定的说明，为了简化表述，此处不再赘述。

对应地，此时步骤203具体包括：通过所述目标处理节点，基于所述待维护运单的实际运输状态，更新所述redis数据库中存储的待维护运单的运输状态。

具体地，可以通过目标处理节点将待维护运单的实际运输状态写回redis数据库，以实现待维护运单的运输状态的更新。

例如，步骤202中从redis数据库中读取到待维护运单的当前运输状态为“运输中”，若新的路由操作信息显示待维护运单处于“派送”操作节点，则在步骤202中可以确定待维护运单的实际运输状态为“派送中”，在步骤203中，可以通过目标处理节点将待维护运单的实际运输状态“派送中”写回redis数据库，从而实现待维护运单的运输状态的更新。

在一些实施例中，redis数据库中存储的待维护运单的状态信息可以是待维护运单的异常状态，待维护运单的实际状态信息是待维护运单的实际异常状态。此时步骤202具体可以包括如下步骤2021B～步骤2022B：

2021B、通过所述预设分布式处理系统的目标处理节点，从redis数据库中读取所述待维护运单的当前异常状态。

2022B、基于所述新的路由操作信息以及所述当前异常状态，确定所述待维护运单的实际异常状态。

步骤2022B中，可以通过预设的异常判定规则、新的路由操作信息、以及redis数据库中存储的待维护运单的当前异常状态，确定待维护运单的实际异常状态。其中，待维护运单的实际异常状态的确定，可以参照运单数据写入redis数据库过程中所介绍的异常状态确定的说明，为了简化表述，此处不再赘述。

对应地，此时步骤203具体包括：通过所述目标处理节点，基于所述待维护运单的实际异常状态，更新所述redis数据库中存储的待维护运单的异常状态。

具体地，可以通过目标处理节点将待维护运单的实际异常状态写回redis数据库，以实现待维护运单的异常状态的更新。

例如，步骤202中从redis数据库中读取到待维护运单的当前异常状态为“滞留”，若新的路由操作信息显示待维护运单处于“中转”操作节点，则在步骤202中可以确定待维护运单的实际异常状态为“中转滞留”，在步骤203中，可以通过目标处理节点将待维护运单的实际异常状态“中转滞留”写回redis数据库，从而实现待维护运单的异常状态的更新。

在一些实施例中，redis数据库中存储的待维护运单的状态信息包括待维护运单的运输状态、待维护运单的异常状态，待维护运单的实际状态信息包括待维护运单的实际运输状态、待维护运单的实际异常状态。此时步骤202具体可以包括如下步骤2021C～步骤2023C：

2021C、通过所述预设分布式处理系统的目标处理节点，从redis数据库中读取所述待维护运单的当前状态运输状态、所述待维护运单的当前异常状态。

步骤2021C的实现与上述步骤2021A和步骤2021B的实现类似，具体可以参照上述说明，此处不再赘述。

2022C、基于所述新的路由操作信息以及所述当前运输状态，确定所述待维护运单的实际运输状态。

步骤2022C的实现与上述步骤2022A的实现类似，具体可以参照上述说明，此处不再赘述。

2023C、基于所述新的路由操作信息以及所述当前异常状态，确定所述待维护运单的实际异常状态。

步骤2023C的实现与上述步骤2022B的实现类似，具体可以参照上述说明，此处不再赘述。

对应地，此时步骤203具体包括：通过所述目标处理节点，基于所述待维护运单的实际运输状态，更新所述redis数据库中存储的待维护运单的运输状态；基于所述待维护运单的实际异常状态，更新所述redis数据库中存储的待维护运单的异常状态。

由以上内容可以看出，本申请实施例中，当检测到redis数据库中记录的待维护运单存在新的路由操作信息时，在redis数据库中添加待维护运单的加锁记录；在待维护运单的加锁记录添加成功时，再对待维护运单的状态数据进行更新，避免了两个或以上的处理节点同时对待维护运单的状态数据进行更新，进而避免了同一运单的运单数据同时更新会出现数据覆盖的情况而导致状态丢失的问题。可见，一方面，由于可以避免物流运单数据高并发更新场景下容易出现数据覆盖情况而导致状态丢失的问题，进而避免运单数据更新不准确的问题，提高了物流运单数据高并发更新场景下的数据更新准确性。另一方面，由于是基于分布式处理系统对运单的状态数据进行更新，因此保证物流运单数据高并发更新需求，保证了运单的状态数据的更新实时性。

进一步地，在“基于所述实际状态信息，更新所述redis数据库中存储的待维护运单的状态数据”的步骤之后，还包括：在所述redis数据库中删除所述待维护运单的加锁记录。

通过在完成对redis数据库中存储的待维护运单的状态数据更新后，对待维护运单进行解锁，进而保证当其他处理节点再次接收到redis数据库中记录的待维护运单存在新的路由操作信息，可以重新进行加锁，进而完成待维护运单的状态数据实时更新。

一般来说，redis数据库可以根据场景需求，动态地进行扩容，以满足物流场景中大运单数据量的存储需求。但由于物流场景中运单数据量大，而一个运单一般只需在揽收和派发期间需要进行状态数据的更新，为了避免redis数据库的数据不断地扩增，以致于超出redis数据库最大容量，可以对存储在redis数据库的待维护运单设置维护周期。在达到维护周期时，将待维护运单的状态数据从redis数据库中删除，以使得redis数据库的数据存储量保持在一个相对平衡的状态，进而在保证待维护运单的状态数据可以实时更新基础上，保证redis数据库的高可用性。

即该运单状态更新方法还包括：获取所述待维护运单存储在所述redis数据库中的存储时长；当所述存储时长大于预设存储周期时长时，从所述redis数据库中删除所述待维护运单的状态数据。

其中，存储时长是指待维护运单的状态数据存储在redis数据库的已累计时长。

例如，待维护运单存储在redis数据库中的存储时长为31天，超出了预设存储周期时长30天，则可以从redis数据库中删除所述待维护运单的状态数据。

其中，此处预设存储周期时长仅为举例，预设存储周期时长的具体取值可以根据实际需求而调整，不以此为限。

由以上内容可以看出，由于一个运单一般只需在揽收和派发期间需要进行状态数据的更新，通过预设存储周期时长，当存储时长大于预设存储周期时长时，从redis数据库中删除待维护运单的状态数据，既可以保证在运单揽收和派发期间状态数据的正常更新，同时又可以避免redis数据库的数据不断地扩增而超出redis数据库最大容量的问题，保证了redis数据库的高可用性。

进一步地，在某些业务场景，需要针对某个特定客户的运单的状态数据进行维护，此时，可以将该特定客户的待维护运单的运单数据处理成一条状态数据存入redis数据库，以便对该特定客户的待维护运单的状态数据进行实时更新。此时，在步骤201之前还可以包括将特定客户的运单数据写入redis数据库的过程：

(1)获取所述目标对象的标识信息。

其中，目标对象是物流公司的特定客户，例如物流公司的月结客户。

标识信息是指目标对象的识别信息，例如月结客户的月结卡号。

(2)根据所述标识信息，从预设的物流数据记录库中获取所述目标对象的运单的路由操作信息集。

一般来说，为了便于物流的精细化管理，物流公司会将物流全网中运单的全部数据，比如，运单的运单号、收寄件人、收发地、路由操作信息等记录在物流数据记录库中。

如图4所示，示例性，可以基于目标对象的标识信息，从物流数据记录库中查询到目标对象的各运单及各运单的路由操作信息，从而得到目标对象的运单的路由操作信息集。

(3)根据所述路由操作信息集，确定所述目标对象的运单的状态数据。

具体地，确定目标对象的运单的状态数据的方式与上述步骤202中确定待维护运单的状态数据类似，具体可以参照上述说明，为简化表述，此处不再赘述。

(4)将所述目标对象的运单的状态数据存储至所述redis数据库。

进一步地，为了满足物流业务场景中对运单状态数据的实时更新需求，还可以按照预设的同步周期，将所述redis数据库所存储的待维护运单的状态数据同步至预设的展示平台；通过所述展示平台，展示所述待维护运单的状态数据。

示例性地，待维护运单是购物平台的购买订单的运单，此时，预设的展示平台可以是购物平台，则可以每间隔2h，将redis数据库所存储的该购买订单的运单的状态数据同步至该购物平台，以供该购物平台可以及时更新购买订单中的物流信息。

其中，预设的同步周期可以是每间隔1h、2h、一天等，具体可以根据实际需求而设置预设的同步周期的具体取值，此处对预设的同步周期的具体取值不作限制。

预设的展示平台可以时购物平台等，预设的展示平台具体可以根据实际场景需求而变，此处对预设的展示平台不作限制。

进一步地，为了提高展示平台的数据展示效率，还可以进一步对redis数据库所存储的待维护运单的状态数据，按照业务维度进行分类，例如，按照收件方的省份、运单的所属仓库、运单状态、运单时效达成情况进行分类并统计后，在展示平台进行展示。

为了更好实施本申请实施例中运单状态更新方法，在运单状态更新方法基础之上，本申请实施例中还提供一种运单状态更新装置，如图5所示，为本申请实施例中运单状态更新装置的一个实施例结构示意图，该运单状态更新装置500包括：

加锁单元501，用于当检测到预设分布式处理系统的redis数据库中记录的待维护运单存在新的路由操作信息时，在所述redis数据库中添加所述待维护运单的加锁记录，其中，所述redis数据库中存储有所述待维护运单的状态数据；

确定单元502，用于当所述待维护运单的加锁记录添加成功时，基于所述新的路由操作信息、以及所述redis数据库中存储的所述待维护运单的当前状态信息，确定所述待维护运单的实际状态信息；

更新单元503，用于基于所述实际状态信息，更新所述redis数据库中存储的待维护运单的状态数据。

在本申请一种可能的实现方式中，所述待维护运单的状态数据包括所述待维护运单的路由操作信息、所述待维护运单的运输状态、所述待维护运单的异常状态中至少一者，所述实际状态信息包括所述待维护运单的实际运输状态和实际异常状态，所述确定单元502具体用于：

通过所述预设分布式处理系统的目标处理节点，从redis数据库中读取所述待维护运单的当前状态运输状态、所述待维护运单的当前异常状态；

基于所述新的路由操作信息以及所述当前运输状态，确定所述待维护运单的实际运输状态；

基于所述新的路由操作信息以及所述当前异常状态，确定所述待维护运单的实际异常状态。

在本申请一种可能的实现方式中，所述加锁单元501具体用于：

通过所述目标处理节点，发起对所述待维护运单的加锁请求；

当所述待维护运单处于解锁状态时，基于所述加锁请求在所述redis数据库中添加所述待维护运单的加锁记录；

在本申请一种可能的实现方式中，所述更新单元503具体用于：

通过所述目标处理节点，基于所述实际状态信息，更新所述redis数据库中存储的待维护运单的状态数据。

在本申请一种可能的实现方式中，所述运单状态更新装置500还包括周期管理单元(图中未示出)，所述周期管理单元具体用于：

获取所述待维护运单存储在所述redis数据库中的存储时长；

当所述存储时长大于预设存储周期时长时，从所述redis数据库中删除所述待维护运单的状态数据。

在本申请一种可能的实现方式中，所述运单状态更新装置500包括存储单元(图中未示出)，所述redis数据库用于存储所述待维护运单为目标对象的运单，在所述当检测到预设分布式处理系统的redis数据库中记录的待维护运单存在新的路由操作信息时，在所述redis数据库中添加所述待维护运单的加锁记录的步骤之前，所述存储单元具体用于：

获取所述目标对象的标识信息；

根据所述标识信息，从预设的物流数据记录库中获取所述目标对象的运单的路由操作信息集；

根据所述路由操作信息集，确定所述目标对象的运单的状态数据；

将所述目标对象的运单的状态数据存储至所述redis数据库。

在本申请一种可能的实现方式中，所述运单状态更新装置500包括同步单元(图中未示出)，所述同步单元具体用于：

按照预设的同步周期，将所述redis数据库所存储的待维护运单的状态数据同步至预设的展示平台；

通过所述展示平台，展示所述待维护运单的状态数据。

在本申请一种可能的实现方式中，所述运单状态更新装置500包括解锁单元(图中未示出)，在所述基于所述实际状态信息，更新所述redis数据库中存储的待维护运单的状态数据的步骤之后，所述解锁单元具体用于：

在所述redis数据库中删除所述待维护运单的加锁记录。

具体实施时，以上各个单元可以作为独立的实体来实现，也可以进行任意组合，作为同一或若干个实体来实现，以上各个单元的具体实施可参见前面的方法实施例，在此不再赘述。

由于该运单状态更新装置可以执行本申请如图1至图4对应任意实施例中运单状态更新方法中的步骤，因此，可以实现本申请如图1至图4对应任意实施例中运单状态更新方法所能实现的有益效果，详见前面的说明，在此不再赘述。

此外，为了更好实施本申请实施例中运单状态更新方法，在运单状态更新方法基础之上，本申请实施例还提供一种电子设备，参阅图6，图6示出了本申请实施例电子设备的一种结构示意图，具体的，本申请实施例提供的电子设备包括处理器601，处理器601用于执行存储器602中存储的计算机程序时实现如图1至图4对应任意实施例中运单状态更新方法的各步骤；或者，处理器601用于执行存储器602中存储的计算机程序时实现如图5对应实施例中各单元的功能。

示例性的，计算机程序可以被分割成一个或多个模块/单元，一个或者多个模块/单元被存储在存储器602中，并由处理器601执行，以完成本申请实施例。一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述计算机程序在计算机装置中的执行过程。

电子设备可包括，但不仅限于处理器601、存储器602。本领域技术人员可以理解，示意仅仅是电子设备的示例，并不构成对电子设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如电子备还可以包括输入输出设备、网络接入设备、总线等，处理器601、存储器602、输入输出设备以及网络接入设备等通过总线相连。

处理器601可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等，处理器是电子设备的控制中心，利用各种接口和线路连接整个电子设备的各个部分。

存储器602可用于存储计算机程序和/或模块，处理器601通过运行或执行存储在存储器602内的计算机程序和/或模块，以及调用存储在存储器602内的数据，实现计算机装置的各种功能。存储器602可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据电子设备的使用所创建的数据(比如音频数据、视频数据等)等。此外，存储器可以包括高速随机存取存储器，还可以包括非易失性存储器，例如硬盘、内存、插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card)、至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的运单状态更新装置、电子设备及其相应单元的具体工作过程，可以参考如图1至图4对应任意实施例中运单状态更新方法的说明，具体在此不再赘述。

本领域普通技术人员可以理解，上述实施例的各种方法中的全部或部分步骤可以通过指令来完成，或通过指令控制相关的硬件来完成，该指令可以存储于一计算机可读存储介质中，并由处理器进行加载和执行。

为此，本申请实施例提供一种计算机可读存储介质，其中存储有多条指令，该指令能够被处理器进行加载，以执行本申请如图1至图4对应任意实施例中运单状态更新方法中的步骤，具体操作可参考如图1至图4对应任意实施例中运单状态更新方法的说明，在此不再赘述。

其中，该计算机可读存储介质可以包括：只读存储器(ROM，Read Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁盘或光盘等。

由于该计算机可读存储介质中所存储的指令，可以执行本申请如图1至图4对应任意实施例中运单状态更新方法中的步骤，因此，可以实现本申请如图1至图4对应任意实施例中运单状态更新方法所能实现的有益效果，详见前面的说明，在此不再赘述。

以上对本申请实施例所提供的一种运单状态更新方法、装置、电子设备及计算机可读存储介质进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (11)

1.一种运单状态更新方法，其特征在于，所述方法包括：

当检测到预设分布式处理系统的redis数据库中记录的待维护运单存在新的路由操作信息时，在所述redis数据库中添加所述待维护运单的加锁记录，其中，所述redis数据库中存储有所述待维护运单的状态数据；

当所述待维护运单的加锁记录添加成功时，基于所述新的路由操作信息、以及所述redis数据库中存储的所述待维护运单的当前状态信息，确定所述待维护运单的实际状态信息；

基于所述实际状态信息，更新所述redis数据库中存储的待维护运单的状态数据。

2.根据权利要求1所述的运单状态更新方法，其特征在于，所述待维护运单的状态数据包括所述待维护运单的路由操作信息、所述待维护运单的运输状态、所述待维护运单的异常状态中至少一者。

3.根据权利要求2所述的运单状态更新方法，其特征在于，所述实际状态信息包括所述待维护运单的实际运输状态和实际异常状态，所述基于所述新的路由操作信息、以及所述redis数据库中存储的所述待维护运单的当前状态信息，确定所述待维护运单的实际状态信息，包括：

通过所述预设分布式处理系统的目标处理节点，从redis数据库中读取所述待维护运单的当前状态运输状态、所述待维护运单的当前异常状态；

基于所述新的路由操作信息以及所述当前运输状态，确定所述待维护运单的实际运输状态；

基于所述新的路由操作信息以及所述当前异常状态，确定所述待维护运单的实际异常状态。

4.根据权利要求3所述的运单状态更新方法，其特征在于，所述在所述redis数据库中添加所述待维护运单的加锁记录，包括：

通过所述目标处理节点，发起对所述待维护运单的加锁请求；

当所述待维护运单处于解锁状态时，基于所述加锁请求在所述redis数据库中添加所述待维护运单的加锁记录；

所述基于所述实际状态信息，更新所述redis数据库中存储的待维护运单的状态数据，包括：

通过所述目标处理节点，基于所述实际状态信息，更新所述redis数据库中存储的待维护运单的状态数据。

5.根据权利要求1所述的运单状态更新方法，其特征在于，所述方法还包括：

获取所述待维护运单存储在所述redis数据库中的存储时长；

当所述存储时长大于预设存储周期时长时，从所述redis数据库中删除所述待维护运单的状态数据。

6.根据权利要求1所述的运单状态更新方法，其特征在于，所述redis数据库用于存储所述待维护运单为目标对象的运单，所述当检测到预设分布式处理系统的redis数据库中记录的待维护运单存在新的路由操作信息时，在所述redis数据库中添加所述待维护运单的加锁记录，之前还包括：

获取所述目标对象的标识信息；

根据所述标识信息，从预设的物流数据记录库中获取所述目标对象的运单的路由操作信息集；

根据所述路由操作信息集，确定所述目标对象的运单的状态数据；

将所述目标对象的运单的状态数据存储至所述redis数据库。

7.根据权利要求1所述的运单状态更新方法，其特征在于，所述方法还包括：

按照预设的同步周期，将所述redis数据库所存储的待维护运单的状态数据同步至预设的展示平台；

通过所述展示平台，展示所述待维护运单的状态数据。

8.根据权利要求1-7任一项所述的运单状态更新方法，其特征在于，所述基于所述实际状态信息，更新所述redis数据库中存储的待维护运单的状态数据，之后还包括：

在所述redis数据库中删除所述待维护运单的加锁记录。

9.一种运单状态更新装置，其特征在于，所述运单状态更新装置包括：

加锁单元，用于当检测到预设分布式处理系统的redis数据库中记录的待维护运单存在新的路由操作信息时，在所述redis数据库中添加所述待维护运单的加锁记录，其中，所述redis数据库中存储有所述待维护运单的状态数据；

确定单元，用于当所述待维护运单的加锁记录添加成功时，基于所述新的路由操作信息、以及所述redis数据库中存储的所述待维护运单的当前状态信息，确定所述待维护运单的实际状态信息；

更新单元，用于基于所述实际状态信息，更新所述redis数据库中存储的待维护运单的状态数据。

10.一种电子设备，其特征在于，包括处理器和存储器，所述存储器中存储有计算机程序，所述处理器调用所述存储器中的计算机程序时执行如权利要求1至8任一项所述的运单状态更新方法。

11.一种计算机可读存储介质，其特征在于，其上存储有计算机程序，所述计算机程序被处理器进行加载，以执行权利要求1至8任一项所述的运单状态更新方法中的步骤。

Images