一种订单修复方法及装置与流程

本申请涉及数据修复领域，具体而言，涉及一种订单修复方法及装置。

背景技术：

目前，设备共享服务发展迅速，例如共享单车、共享汽车、共享移动电源等设备共享服务层出不穷，由于共享设备的使用是完全自助化的，因此当发生意外故障时，订单的修复成为了一大技术难点。

现有技术中，用户端在向服务器请求使用共享设备时，可能出现共享设备启用超时的情况(例如，用户端发送使用请求后超过30s以上用户端显示未启用时，该订单的情况为启用超时)。造成这种情况的原因可能是由于网络问题或设备故障，设备已启用成功，但是由于设备未将启用成功的信息及时反馈给服务器，导致用户端显示启用失败，并且服务器不能完整记录设备的服务订单详情，导致设备漏单，同时，用户也无法正常结束订单。

技术实现要素：

有鉴于此，本申请的目的在于提供一种订单修复方法及装置，达到提高了服务订单的完整度，从而提高了订单系统的稳定性。

根据本申请的一个方面，提供一种电子设备，可以包括存储介质和与存储介质通信的处理器。存储介质存储有处理器可执行的机器可读指令。当电子设备运行时，处理器与存储介质之间通过总线通信，处理器执行所述机器可读指令，以执行以下操作：

一种订单修复方法，该方法包括：

在接收到服务请求端发送的针对目标服务提供端的使用请求后，向所述目标服务提供端发送开锁指令；

若未在第一预设时间内接收到所述目标服务提供端返回的关于所述开锁指令的开锁成功信息，则计算发送所述开锁指令后，所述目标服务提供端的实际行驶数据和所述服务请求端的历史行驶数据的相似度；

根据所述相似度的数值，确定是否对所述使用请求所对应的服务订单进行修复。

在一些实施例中，若未在第一预设时间内接收到所述目标服务提供端返回的关于所述开锁指令的开锁成功信息，则计算发送所述开锁指令后，所述目标服务提供端的实际行驶数据和所述服务请求端的历史行驶数据的相似度，包括：

若所述目标服务提供端在发送所述开锁指令后的实际行驶位移超过预设位移，且未在第一预设时间内接收到所述目标服务提供端返回的关于所述开锁指令的开锁成功信息，则计算发送所述开锁指令后，所述目标服务提供端的实际行驶数据和所述服务请求端的历史行驶数据的相似度。

在一些实施例中，所述若所述目标服务提供端在发送所述开锁指令后的实际行驶位移超过预设位移，且未在第一预设时间内接收到所述目标服务提供端返回的关于所述开锁指令的开锁成功信息，则计算发送所述开锁指令后，所述目标服务提供端的实际行驶数据和所述服务请求端的历史行驶数据的相似度，该方法包括：

若所述目标服务提供端所对应的目标上报点的数量超过预设数量，且所述目标服务提供端在发送所述开锁指令后的实际行驶位移超过预设位移，以及未在第一预设时间内接收到所述目标服务提供端返回的关于所述开锁指令的开锁成功信息，则计算发送所述开锁指令后，所述目标服务提供端的实际行驶数据和所述服务请求端的历史行驶数据的相似度；所述目标上报点是目标服务提供端在行驶过程中车轮转速超过预设数值的上报点。

在一些实施例中，若未在第一预设时间内接收到所述目标服务提供端返回的关于所述开锁指令的开锁成功信息，则计算发送所述开锁指令后，所述目标服务提供端的实际行驶数据和所述服务请求端的历史行驶数据的相似度，包括：

若所述目标服务提供端所对应的目标上报点的数量超过预设数量，且未在第一预设时间内接收到所述目标服务提供端返回的关于所述开锁指令的开锁成功信息，则计算发送所述开锁指令后，所述目标服务提供端的实际行驶数据和所述服务请求端的历史行驶数据的相似度；所述目标上报点是目标服务提供端在行驶过程中车轮转速超过预设数值的上报点。

在一些实施例中，若未在第一预设时间内接收到所述目标服务提供端返回的关于所述开锁指令的开锁成功信息，则计算发送所述开锁指令后，所述目标服务提供端的实际行驶数据和所述服务请求端的历史行驶数据的相似度，包括：

若未在第二预设时间内产生使用所述目标服务提供端或由所述服务请求端发起的服务订单，且未在第一预设时间内接收到所述目标服务提供端返回的关于所述开锁指令的开锁成功信息，则计算发送所述开锁指令后，所述目标服务提供端的实际行驶数据和所述服务请求端的历史行驶数据的相似度；所述第二预设时间的时间长度大于或等于所述第一预设时间的时间长度。

在一些实施例中，计算发送所述开锁指令后，所述目标服务提供端的实际行驶数据和所述服务请求端的历史行驶数据的相似度，包括：

计算发送所述开锁指令后，所述目标服务提供端的实际行驶轨迹和每个所述服务请求端的历史行驶轨迹的轨迹相似度；

将所述轨迹相似度中数值最大的目标轨迹相似度作为所述目标服务提供端的实际行驶数据和所述服务请求端的历史行驶数据的相似度。

在一些实施例中，历史行驶数据的相似度包括重力相似度和目标轨迹相似度；

计算发送所述开锁指令后，所述目标服务提供端的实际行驶数据和所述服务请求端的历史行驶数据的相似度，包括：

计算发送所述开锁指令后，所述目标服务提供端的实际行驶轨迹和每个所述服务请求端的历史行驶轨迹的轨迹相似度；

计算发送所述开锁指令后，所述目标服务提供端上设置的座椅重力感应装置采集的当前座椅重力值和所述服务请求端的历史座椅重力值的重力相似度；

根据所述历史行驶数据的相似度的数值，确定是否对所述使用请求所对应的服务订单进行修复，包括：

根据所述轨迹相似度中数值最大的目标轨迹相似度与所述重力相似度，确定是否对所述使用请求所对应的服务订单进行修复。

在一些实施例中，根据所述相似度的数值，确定是否对所述使用请求所对应的服务订单进行修复，包括：

若所述轨迹相似度中数值最大的目标轨迹相似度高于第一阈值，且所述重力相似度高于第二阈值，则对所述使用请求所对应的服务订单进行修复。

在一些实施例中，根据所述相似度的数值，确定是否对所述使用请求所对应的服务订单进行修复，还包括：

若所述轨迹相似度中数值最大的目标轨迹相似度低于第一阈值，且所述重力相似度高于第二阈值，则向所述服务请求端发送订单确认消息；

根据接收到所述服务请求端对所述订单确认消息的反馈消息，确定是否对所述使用请求所对应的服务订单进行修复。

在一些实施例中，计算发送所述开锁指令后，所述目标服务提供端的实际行驶数据和所述服务请求端的历史行驶数据的相似度，包括：

计算发送所述开锁指令后，所述目标服务提供端上设置的座椅重力感应装置采集的当前座椅重力值和所述服务请求端的历史座椅重力值的重力相似度；

将所述重力相似度作为所述目标服务提供端的实际行驶数据和所述服务请求端的历史行驶数据的相似度。

另一方面，本申请还提供了一种订单修复装置，该装置包括：

通信模块，用于在接收到服务请求端发送的针对目标服务提供端的使用请求后，向所述目标服务提供端发送开锁指令；

计算模块，用于若未在第一预设时间内接收到所述目标服务提供端返回的关于所述开锁指令的开锁成功信息，则计算发送所述开锁指令后，所述目标服务提供端的实际行驶数据和所述服务请求端的历史行驶数据的相似度；

修复模块，用于根据所述相似度的数值，确定是否对所述使用请求所对应的服务订单进行修复。

在一些实施例中，计算模块，包括：

位移单元，用于若所述目标服务提供端在发送所述开锁指令后的实际行驶位移超过预设位移，且未在第一预设时间内接收到所述目标服务提供端返回的关于所述开锁指令的开锁成功信息，则计算发送所述开锁指令后，所述目标服务提供端的实际行驶数据和所述服务请求端的历史行驶数据的相似度。

在一些实施例中，计算模块，包括：

轮速位移单元，用于若所述目标服务提供端所对应的目标上报点的数量超过预设数量，且所述目标服务提供端在发送所述开锁指令后的实际行驶位移超过预设位移，以及未在第一预设时间内接收到所述目标服务提供端返回的关于所述开锁指令的开锁成功信息，则计算发送所述开锁指令后，所述目标服务提供端的实际行驶数据和所述服务请求端的历史行驶数据的相似度；所述目标上报点是目标服务提供端在行驶过程中车轮转速超过预设数值的上报点。

在一些实施例中，计算模块，包括：

轮速单元，用于若所述目标服务提供端所对应的目标上报点的数量超过预设数量，且未在第一预设时间内接收到所述目标服务提供端返回的关于所述开锁指令的开锁成功信息，则计算发送所述开锁指令后，所述目标服务提供端的实际行驶数据和所述服务请求端的历史行驶数据的相似度；所述目标上报点是目标服务提供端在行驶过程中车轮转速超过预设数值的上报点。

在一些实施例中，计算模块，包括：

查询单元，用于若未在第二预设时间内产生使用所述目标服务提供端或由所述服务请求端发起的服务订单，且未在第一预设时间内接收到所述目标服务提供端返回的关于所述开锁指令的开锁成功信息，则计算发送所述开锁指令后，所述目标服务提供端的实际行驶数据和所述服务请求端的历史行驶数据的相似度；所述第二预设时间的时间长度大于或等于所述第一预设时间的时间长度。

在一些实施例中，计算模块，还包括：

轨迹单元，用于计算发送所述开锁指令后，所述目标服务提供端的实际行驶轨迹和每个所述服务请求端的历史行驶轨迹的轨迹相似度；将所述轨迹相似度中数值最大的目标轨迹相似度作为所述目标服务提供端的实际行驶数据和所述服务请求端的历史行驶数据的相似度。

在一些实施例中，计算模块还包括组合单元，修复模块包括组合修复单元：其中

组合单元，用于计算发送所述开锁指令后，所述目标服务提供端的实际行驶轨迹和每个所述服务请求端的历史行驶轨迹的轨迹相似度；计算发送所述开锁指令后，所述目标服务提供端上设置的座椅重力感应装置采集的当前座椅重力值和所述服务请求端的历史座椅重力值的重力相似度；

组合修复单元，用于根据所述轨迹相似度中数值最大的目标轨迹相似度与所述重力相似度，确定是否对所述使用请求所对应的服务订单进行修复。

在一些实施例中，修复模块，还包括：

第一修复单元，用于若所述轨迹相似度中数值最大的目标轨迹相似度高于第一阈值，且所述重力相似度高于第二阈值，则对所述使用请求所对应的服务订单进行修复。

在一些实施例中，修复模块，还包括：

第二修复单元，用于若所述轨迹相似度中数值最大的目标轨迹相似度低于第一阈值，且所述重力相似度高于第二阈值，则向所述服务请求端发送订单确认消息；根据接收到所述服务请求端对所述订单确认消息的反馈消息，确定是否对所述使用请求所对应的服务订单进行修复。

在一些实施例中，计算模块，还包括：

重力单元，用于计算发送所述开锁指令后，所述目标服务提供端上设置的座椅重力感应装置采集的当前座椅重力值和所述服务请求端的历史座椅重力值的重力相似度；将所述重力相似度作为所述目标服务提供端的实际行驶数据和所述服务请求端的历史行驶数据的相似度。

本申请所提供的方案的某一实施例，在服务器根据服务请求端针对目标服务提供端的使用请求，向目标服务器提供端发送了开锁指令后，且在第一预设时间内未接收到目标服务提供端的反馈时，计算发送开锁指令后目标服务提供端的实际行驶数据与服务请求端的历史行驶数据的相似度，并根据相似度的数值来确定是否对服务订单进行修改。具体如：若相似度达到预设阈值，则根据目标服务提供端的实际行驶数据对该服务订单进行修复；若相似度未达到预设阈值，则将该服务订单标为无效，并放弃修复。由此可见，本申请所提供的方案基于目标服务提供端的实际行驶数据与服务请求端的历史行驶数据的相似度来进行判断，当前使用目标服务提供端的对象是否是持有该服务请求端的对象，当前使用目标服务提供端的对象是持有该服务请求端的对象的时候，才会对订单进行修复，以保证开锁的对象能够正常使用车辆；在订单系统上，实现了在订单超时情况下对订单修复的自动判断，提高了服务订单的完整度，从而提高了订单系统的稳定性。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本申请实施例提供的一种订单系统的架构示意图；

图2示出了本申请实施例提供的一种订单修复方法的流程图；

图3示出了本申请实施例提供的一种订单修复装置的结构示意图；

图4示出了本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，应当理解，本申请中附图仅起到说明和描述的目的，并不用于限定本申请的保护范围。另外，应当理解，示意性的附图并未按实物比例绘制。本申请中使用的流程图示出了根据本申请的一些实施例实现的操作。应该理解，流程图的操作可以不按顺序实现，没有逻辑的上下文关系的步骤可以反转顺序或者同时实施。此外，本领域技术人员在本申请内容的指引下，可以向流程图添加一个或多个其他操作，也可以从流程图中移除一个或多个操作。

另外，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

为了使得本领域技术人员能够使用本申请内容，结合特定应用场景“共享单车”，给出以下实施方式。对于本领域技术人员来说，在不脱离本申请的精神和范围的情况下，可以将这里定义的一般原理应用于其他实施例和应用场景。虽然本申请主要围绕共享单车进行描述，但是应该理解，这仅是一个示例性实施例。

需要说明的是，本申请实施例中将会用到术语“包括”，用于指出其后所声明的特征的存在，但并不排除增加其它的特征。

本申请的一个方面涉及一种订单修复方法。该方法在服务器根据服务请求端针对目标服务提供端的使用请求，向目标服务器提供端发送了开锁指令后而在第一预设时间内未接收到目标服务提供端的反馈时，通过计算发送开锁指令后目标服务提供端的实际行驶数据与服务请求端的历史行驶数据的相似度来确认是否需要对服务订单进行修复。

图1是本申请实施例提供的一种订单系统100的架构示意图。例如，订单系统100可以是用于诸如共享单车、共享汽车等的设备共享服务。订单系统100可以包括服务器110、网络、服务请求端120、服务提供端130、和数据库140中的一种或多种。

在一些实施例中，服务器110可以包括处理器。处理器可以处理与服务请求有关的信息和/或数据，以执行本申请中描述的一个或多个功能。例如，处理器可以基于从服务请求端120获得的服务请求来确定目标服务提供端。在一些实施例中，处理器可以包括一个或多个处理核(例如，单核处理器(s)或多核处理器(s))。仅作为举例，处理器可以包括中央处理单元(centralprocessingunit,cpu)、专用集成电路(applicationspecificintegratedcircuit,asic)、专用指令集处理器(applicationspecificinstruction-setprocessor,asip)、图形处理单元(graphicsprocessingunit,gpu)、物理处理单元(physicsprocessingunit,ppu)、数字信号处理器(digitalsignalprocessor,dsp)、现场可编程门阵列(fieldprogrammablegatearray,fpga)、可编程逻辑器件(programmablelogicdevice,pld)、控制器、微控制器单元、简化指令集计算机(reducedinstructionsetcomputing,risc)、或微处理器等，或其任意组合。

在一些实施例中，服务请求端120和服务提供端130对应的设备类型可以是移动设备，比如可以包括智能家居设备、可穿戴设备、智能移动设备、虚拟现实设备、或增强现实设备等，也可以是平板计算机、膝上型计算机、或机动服务提供端中的内置设备等。

在一些实施例中，数据库140可以连接到网络以与订单系统100中的一个或多个组件(例如，服务器110，服务请求端120，服务提供端130等)通信。订单系统100中的一个或多个组件可以经由网络访问存储在数据库140中的数据或指令。在一些实施例中，数据库140可以直接连接到订单系统100中的一个或多个组件，或者，数据库140也可以是服务器110的一部分。

传统方案中，订单系统在运作时是按照如下步骤进行的：

步骤1，服务请求端根据用户的操作，生成使用请求，并向服务器发送该使用请求；

步骤2，服务器根据使用请求生成对应的服务订单；

步骤3，服务器根据使用请求中的目标服务提供端生成开锁指令并下给目标服务提供端；

步骤4，目标服务提供端执行开锁指令，使目标服务提供端可以用户被正常使用；

步骤5，目标服务提供端生成开锁成功信息，并发送给服务器；

步骤6，服务器开始对该服务订单进行计时，并将开锁成功信息发送给服务请求端；

步骤7，服务请求端显示开锁成功信息，用户开始使用目标服务提供端；

步骤8，目标服务提供端在被用户使用的过程中按照预定的频率上报状态信息(如位置、车轮转速)到服务器；

步骤9，在用户使用完目标服务提供端之后，目标服务提供端根据用户的关锁操作，将自身进行关闭，并生成锁定信息，以及将锁定信息发送给服务器；

步骤10，服务器根据锁定信息结束服务订单，并进行计费，而后并将服务订单结束信息发送给服务请求端。

在传统方案中，步骤5中，可能会由于网络问题或目标服务提供端故障导致目标服务提供端虽然执行了开锁指令，但无法将开锁成功信息顺利发送至服务器，此时，服务器会将该服务订单标为超时订单，传统的解决方案有两种：一种是服务器生成开锁失败信息发送给服务请求端，并关闭该服务订单；另一种是服务器默认目标服务提供端已开锁成功，正常对该服务订单进行计时，直至接受到目标服务提供端返回的锁定信息。上述第一种解决方案会导致服务订单的缺失；第二种解决方案会存在非持有服务请求端的用户使用了目标服务提供端的情况。

因此，本申请提出了订单修复方法，以服务器发送开锁指令后目标服务提供端的实际行驶数据与服务请求端的历史行驶数据的相似度作为判断是否是服务请求端的用户本人使用了该目标服务提供端，从而判断是否需要进行订单修复，提高了订单系统的订单准确度。

下面结合上述图1示出的订单系统100中描述的内容，对本申请实施例提供的一种订单修复方法进行详细说明。

参照图2所示，为本申请实施例提供的一种订单修复方法的流程示意图，该方法可以由订单系统100中的服务器110来执行，具体执行过程为：

步骤s201、在接收到服务请求端发送的针对目标服务提供端的使用请求后，向上述目标服务提供端发送开锁指令；

步骤s202、若未在第一预设时间内接收到上述目标服务提供端返回的关于上述开锁指令的开锁成功信息，则计算发送上述开锁指令后，上述目标服务提供端的实际行驶数据和上述服务请求端的历史行驶数据的相似度；

步骤s203、根据上述相似度的数值，确定是否对上述使用请求所对应的服务订单进行修复。

具体地，在步骤s201中，服务请求端是使用订单系统管理的服务提供端的用户所持有的客户端，例如：智能手机、平板电脑等；服务提供端是订单系统管理的服务提供端，例如：共享单车、共享汽车等；使用请求是服务请求端在通过扫码、近场通讯等方式获取目标服务提供端的标识后，生成的使用目标服务提供端的请求；开锁指令是服务器向目标服务提供端下达控制该目标服务提供端上的设置的实体锁解锁，或控制目标服务提供端中能够使目标服务提供端提供服务的线路连通等使目标服务提供端可以正常使用的指令。

在步骤s202中，第一预设时间是服务器从向目标服务提供端发送开锁指令开始计时的等待反馈时间，由于一般情况下服务提供端在接收到开锁指令后，应在一定时间内反馈开锁成功信息，因此需要设置第一预设时间，以通过时间判断目标服务提供端出现了故障，从而进行接下来的处理；其中，开锁成功信息是目标服务提供端在接收到开锁指令后，解锁目标服务提供端上的设置的实体锁，或连通目标服务提供端中能够使目标服务提供端提供服务的线路等使目标服务提供端可以正常使用操作后，生成的反映目标服务提供端可以正常使用的状态信息；相似度是目标服务提供端的实际行驶数据与服务请求端的历史行驶数据中，分别存有的相同类型的数据进行对比计算后得到的相似比例，例如，目标服务提供端的实际行驶数据与服务请求端的历史行驶数据中的轨迹数据的相似比例，又或者是目标服务提供端的实际行驶数据与服务请求端的历史行驶数据中的用户重力值的相似比例等。

在步骤s203中，修复是指对超时的服务订单进行的修复操作，超时的服务订单是由于未在第一预设时间内接收到上述目标服务提供端返回的关于上述开锁指令的开锁成功信息而产生的，下面举例说明具体的修复方式：

(1)修复方式可以是根据上述目标服务提供端的实际行驶数据，生成新的服务订单，以替换超时的服务订单；

(2)修复方式可以是根据上述目标服务提供端的实际行驶数据，对超时的服务订单中对应的数据进行修复。

实际行驶数据包括目标服务提供端的行驶轨迹、在行程中座位重力感应装置检测到的重力值等行驶相关数据。同理，历史行驶数据包括服务请求端的历史行驶轨迹、上次使用服务提供端时记录座位重力感应装置检测到的重力值等。

服务器在接收到服务请求端针对目标服务提供端的使用请求后，根据该使用请求中携带的目标服务提供端的标识，向目标服务提供端发送开锁指令。在第一预设时间内若没有接收到目标服务提供端反馈的开锁状态信息，该服务订单则处于超时状态。

此时，就需要对该订单是否需要修复进行判断。因此，通过计算目标服务提供端的实际行驶数据和服务请求端的历史行驶数据，得到相似度。需要说明的是目标服务提供端的实际行驶数据一般只取发送上述开锁指令后一定时间内的行驶数据，该时间是由历史服务订单中的使用时间的频率来确定的，一般为5分钟，若使用过长时间内的行驶数据，数据量较大，计算占用服务器资源过大；若使用过短时间内的行驶数据，数据量较小，计算结果的可信度不足。

根据相似度是否达到预设阈值来判断是否进行订单修复进程，如果相似度达到预设阈值，说明目标服务提供端是持有服务请求端的用户本人使用的，则进行订单修复；如果相似度未达到预设阈值，说明目标服务提供端不是持有服务请求端的用户本人使用的，则不进行订单修复，以保证用户的财产、信誉等不受到损失。

为了减少服务器订单修复的负荷，在进行相似度计算之前，可进行初步判断，避免目标服务提供端虽然已经接收了开锁指令但未被使用的情况，以及在积累目标服务提供端的实际行驶数据的时间内产生了目标服务提供端被使用或者服务请求端使用其他服务提供端的新服务订单的情况。

一种可能的实施方式中，步骤s202，包括：

步骤301、若上述目标服务提供端在发送上述开锁指令后的实际行驶位移超过预设位移，且未在第一预设时间内接收到上述目标服务提供端返回的关于上述开锁指令的开锁成功信息，则计算发送上述开锁指令后，上述目标服务提供端的实际行驶数据和上述服务请求端的历史行驶数据的相似度。

具体地，由于目标服务提供端上报的实际行驶位移可能是由于定位漂移造成的，因此，为了避免该情况，需要通过目标服务提供端的实际行驶位移来进行初步判断。

在第一预设时间内未接收到上述目标服务提供端返回的关于上述开锁指令的开锁成功信息的同时，该目标服务提供端的实际行驶位移超过了预设位移，才确认目标服务提供端发生了真实的行驶。

例如，在共享单车的使用场景下，预设位移设置为100m，当服务器在发送开锁指令30s后仍未接收到目标单车的开锁状态信息，获取到目标单车的实际行驶位移为200m，超过预设位移的100m，确认目标单车发生了真实行驶，进行后续的流程。

一种可能的实施方式中，步骤s202，包括：

步骤302、若上述目标服务提供端所对应的目标上报点的数量超过预设数量，且上述目标服务提供端在发送上述开锁指令后的实际行驶位移超过预设位移，以及未在第一预设时间内接收到上述目标服务提供端返回的关于上述开锁指令的开锁成功信息，则计算发送上述开锁指令后，上述目标服务提供端的实际行驶数据和上述服务请求端的历史行驶数据的相似度；上述目标上报点是目标服务提供端在行驶过程中车轮转速超过预设数值的上报点。

具体地，在某些情况下即使目标服务提供端在发送上述开锁指令后的实际行驶位移超过了预设位移，但未发生真实行驶。例如，目标服务提供端被非用户搬运、挪动。

因此，为了在初步判断的过程中将上述情况排除，除了对目标服务提供端的实际行驶位移外还对目标服务提供端在各上报点的车轮转速作为判断条件。目标服务提供端会以固定的时间间隔定时发送状态数据给服务器，上报数据的位置称作上报点。

由于目标服务提供端在被使用中不会一直处于行驶的状态(可能因为信号灯等原因停留)，不能保证每个上报点目标服务提供端的车轮转速都超过预设数值。因此以车轮转速超过预设数值的上报点的数量，即目标上报点的数量，超过预设数量作为判断目标服务提供端发生了真实行驶的条件之一。

例如，在共享单车的使用场景下，预设位移设置为100m，共享单车的数据上报时间间隔为30s，预设车轮转速为0，预设数量为5，当服务器在发送开锁指令30s后仍未接收到目标单车的开锁状态信息，获取到目标单车的实际行驶位移为200m，超过预设位移的100m，目标单车在5min中内的10个上报点中有7个上报点的车轮转速大于0，目标上报点的数量超过了预设数量，因此，确认目标单车发生了真实行驶，进行后续的流程。

一种可能的实施方式中，步骤s202，包括：

步骤303、若上述目标服务提供端所对应的目标上报点的数量超过预设数量，且未在第一预设时间内接收到上述目标服务提供端返回的关于上述开锁指令的开锁成功信息，则计算发送上述开锁指令后，上述目标服务提供端的实际行驶数据和上述服务请求端的历史行驶数据的相似度；上述目标上报点是目标服务提供端在行驶过程中车轮转速超过预设数值的上报点。

具体地，通过超过车轮转速预设数值的上报点的数量超过预设数量，以判断目标服务提供端发生真实行驶。

例如，在共享单车的使用场景下，共享单车的数据上报时间间隔为30s，预设车轮转速为0，预设数量为4，当服务器在发送开锁指令30s后仍未接收到目标单车的开锁状态信息，获取到目标单车在5min中内的10个上报点中有6个上报点的车轮转速大于0，目标上报点的数量超过了预设数量，因此，确认目标单车发生了真实行驶，进行后续的流程。

一种可能的实施方式中，步骤s202，包括：

步骤304、若未在第二预设时间内产生使用上述目标服务提供端或由上述服务请求端发起的服务订单，且未在第一预设时间内接收到上述目标服务提供端返回的关于上述开锁指令的开锁成功信息，则计算发送上述开锁指令后，上述目标服务提供端的实际行驶数据和上述服务请求端的历史行驶数据的相似度；所述第二预设时间的时间长度大于或等于所述第一预设时间的时间长度。

具体地，上述第二预设时间是目标服务提供端的实际行驶数据对应时间段。由于要在未在第一预设时间内接收到上述目标服务提供端返回的关于上述开锁指令的开锁成功信息的情况下，才进行确认是否产生使用上述目标服务提供端或由上述服务请求端发起的服务订单，因此第二预设时间的时间长度要大于或等于第一预设时间的时间长度。

在目标服务提供端的实际行驶数据对应的时间段内，若出现了使用目标服务提供端或上述服务请求端发起的新的服务订单，就可以认为目标服务提供端未被持有上述服务请求端的用户使用，停止进行后续流程。

如果未出现上述新的服务订单，那么就需要进行后续的相似度计算来判断是否修复订单。

例如，第二预设时间为5min，服务器接收到客户端发送的对目标单车的使用请求，服务器在向目标单车发送开锁指令后30s内未收到目标单车返回的开锁状态信息，在服务器向目标单车发送开锁指令后2min，服务器接收到了上述客户端发送的对另一单车的使用请求，生成了新的服务订单，因此，确认持有上述客户端的用户未使用目标单车，停止上述客户端对目标单车的超时订单修复的后续流程。

在进行了上述一种或多种初步判断后，排除了可通过简单判断就可筛选的非持有服务请求端的用户本人使用目标服务提供端的超时订单，下面通过几种可能的实施方式说明相似度计算的具体执行过程：

一种可能的实施方式中，步骤s202中，计算发送上述开锁指令后，上述目标服务提供端的实际行驶数据和上述服务请求端的历史行驶数据的相似度，包括：

步骤401、计算发送上述开锁指令后，上述目标服务提供端的实际行驶轨迹和每个上述服务请求端的历史行驶轨迹的轨迹相似度；

步骤402、将上述轨迹相似度中数值最大的目标轨迹相似度作为上述目标服务提供端的实际行驶数据和上述服务请求端的历史行驶数据的相似度。

具体地，上述轨迹相似度是通过实际行驶轨迹中均匀分布的轨迹点与服务请求端的历史行驶轨迹中的轨迹点进行比对计算得到的。通过比对计算得到多个待选轨迹相似度后，选取待选轨迹相似度中数值最大的作为目标相似度，也就是，目标服务提供端的实际行驶数据和上述服务请求端的历史行驶数据的相似度。

持有服务请求端的用户在过去使用该服务器所属的订单系统的服务提供端时生成了多条行驶轨迹，若该用户当前使用目标服务提供端行驶的路线是该用户的常用路线，那么当前目标服务提供端的实际行驶轨迹与上述服务请求端的历史行驶轨迹中的至少一条的轨迹相似度就能够达到预设的相似度阈值。反之，若不是该用户使用的目标服务提供端，那么目标服务提供端的实际行驶轨迹与上述服务请求端的历史行驶轨迹中任一条的轨迹相似度都达不到预设的相似度阈值。

一种可能的实施方式中，步骤s202，包括：

步骤403、计算发送上述开锁指令后，上述目标服务提供端上设置的座椅重力感应装置采集的当前座椅重力值和上述服务请求端的历史座椅重力值的重力相似度；

步骤404、将上述重力相似度作为上述目标服务提供端的实际行驶数据和上述服务请求端的历史行驶数据的相似度。

具体地，目标服务提供端的座椅上设置了重力感应装置，在有用户使用目标服务提供端时，该重力感应装置就会检测用户的体重，并将该数值记录在服务请求端的历史行驶数据中，通过目标服务提供端当前座椅上的重力感应装置检测到的重力值是否与上述服务请求端中上一次使用该订单系统下的服务提供端时记录的重力值的相似度达到预设的相似度阈值，就可判断是否持有上述服务请求端的用户本人使用目标服务提供端。因此，使用重力相似度作为目标服务提供端的实际行驶数据和上述服务请求端的历史行驶数据的相似度。

例如，持有客户端的用户的历史体重为60kg，设置在目标单车的座椅上的重力感应装置检测到当前座椅重力值为500n，即当前使用目标单车的用户的体重约为51kg，重力相似度约为0.85。

一种可能的实施方式中，历史行驶数据的相似度包括重力相似度和目标轨迹相似度；

步骤s202中，计算发送上述开锁指令后，上述目标服务提供端的实际行驶数据和上述服务请求端的历史行驶数据的相似度，包括：

步骤405、计算发送所述开锁指令后，所述目标服务提供端的实际行驶轨迹和每个所述服务请求端的历史行驶轨迹的轨迹相似度；

步骤406、计算发送所述开锁指令后，所述目标服务提供端上设置的座椅重力感应装置采集的当前座椅重力值和所述服务请求端的历史座椅重力值的重力相似度；

根据所述历史行驶数据的相似度的数值，确定是否对所述使用请求所对应的服务订单进行修复，包括：

步骤407、根据所述轨迹相似度中数值最大的目标轨迹相似度与所述重力相似度，确定是否对所述使用请求所对应的服务订单进行修复。

具体的，为了提高相似度的可信度，可以将重力相似度和轨迹相似度同时作为判断是否是持有上述服务请求端的用户本人使用目标服务提供端的参考值。

在使用由重力相似度和轨迹相似度共同来进行判断时，可以对重力相似度和轨迹相似度采用多种不同的处理方式，例如，取重力相似度和轨迹相似度之和、平均值、方差等，但由于重力相似度和轨迹相似度是分别作为判断的参考值，因此，优选地，选择重力相似度和轨迹相似度分别与对应的阈值进行比较，综合重力相似度和轨迹相似度的比较结果，对超时订单是否进行修复进行判断。下面对该优选处理方式的具体执行过程进行说明：

一种可能的实施方式中，步骤s203，包括：

步骤501、若上述轨迹相似度中数值最大的目标轨迹相似度高于第一阈值，且上述重力相似度高于第二阈值，则对上述使用请求所对应的服务订单进行修复。

具体地，第一阈值和第二阈值的具体数值可以相同也可以不同。在轨迹相似度中数值最大的目标轨迹相似度高于第一阈值，同时，重力相似度高于第二阈值的情况下，就可以确认是持有上述服务请求端的用户使用目标服务提供端，那么，就根据目标服务提供端的实际行驶数据对该超时订单进行修复。

例如，目标单车的实际行驶轨迹和客户端的各个历史行驶轨迹的轨迹相似度中数值最大的目标轨迹相似度为0.93，目标单车上设置的重力感应装置采集的当前座椅重力值和客户端记录的历史重力值的重力相似度为0.96，第一阈值为0.90，第二阈值为0.95，轨迹相似度中数值最大的目标轨迹相似度高于第一阈值，且重力相似度高于第二阈值，因此，确认是持有上述客户端的用户使用目标单车，根据目标单车的实际行驶数据，对上述客户端使用目标单车的超时订单进行订单修复。

一种可能的实施方式中，步骤s203，还包括：

步骤502、若上述轨迹相似度中数值最大的目标轨迹相似度低于第一阈值，且上述重力相似度高于第二阈值，则向上述服务请求端发送订单确认消息；

步骤503、根据接收到上述服务请求端对上述订单确认消息的反馈消息，确定是否对上述使用请求所对应的服务订单进行修复。

具体地，在实际使用场景下，可能存在虽然是持有上述服务请求端的用户使用了目标服务提供端，但由于该用户第一次使用该订单系统下的服务提供端行驶该路线。在该种情况下，重力相似度必然高于上述第二阈值，且轨迹相似度中数值最大的目标轨迹相似度低于上述第一阈值。

因此，当出现上述情况时，服务器向上述服务请求端发送订单确认消息，请求用户反馈是否是本人使用目标服务提供端，以确定是否根据目标服务提供端的实际行驶数据对该超时订单进行修复。

例如，目标单车的实际行驶轨迹和客户端的各个历史行驶轨迹的轨迹相似度中数值最大的目标轨迹相似度为0.30，目标单车上设置的重力感应装置采集的当前座椅重力值和客户端记录的历史重力值的重力相似度为0.98，第一阈值为0.90，第二阈值为0.95，轨迹相似度中数值最大的目标轨迹相似度低于第一阈值，且重力相似度高于第二阈值，服务器向上述客户端发送订单确认消息，并接收到了该客户端返回的确认回复消息，因此，确认是持有上述客户端的用户使用目标单车，根据目标单车的实际行驶数据，对上述客户端使用目标单车的超时订单进行订单修复。

该实施方式下，在该特殊情况下虽然仍需要用户进行反馈已确定是否需要进行订单修复，但相对于传统的不进行判断和计算就默认让用户进行反馈已确定是否进行订单修复的现有方案，大幅减少了需要用户进行反馈的超时订单数量。

基于同一发明构思，本申请实施例中还提供了与订单修复方法对应的订单修复装置，由于本申请实施例中的装置解决问题的原理与本申请实施例上述订单修复方法相似，因此装置的实施可以参见方法的实施，重复之处不再赘述。

参照图3所示，为本申请提供的一种订单修复装置的结构示意图，所述装置包括：通信模块、计算模块、修复模块；其中，

通信模块61，用于在接收到服务请求端发送的针对目标服务提供端的使用请求后，向上述目标服务提供端发送开锁指令；

计算模块62，用于若未在第一预设时间内接收到上述目标服务提供端返回的关于上述开锁指令的开锁成功信息，则计算发送上述开锁指令后，上述目标服务提供端的实际行驶数据和上述服务请求端的历史行驶数据的相似度；

修复模块63，用于根据上述相似度的数值，确定是否对上述使用请求所对应的服务订单进行修复。

一种可能的实施方式中，计算模块62，包括：

位移单元621，用于若上述目标服务提供端在发送上述开锁指令后的实际行驶位移超过预设位移，且未在第一预设时间内接收到上述目标服务提供端返回的关于上述开锁指令的开锁成功信息，则计算发送上述开锁指令后，上述目标服务提供端的实际行驶数据和上述服务请求端的历史行驶数据的相似度。

一种可能的实施方式中，计算模块62，包括：

轮速位移单元622，用于若上述目标服务提供端所对应的目标上报点的数量超过预设数量，且上述目标服务提供端在发送上述开锁指令后的实际行驶位移超过预设位移，以及未在第一预设时间内接收到上述目标服务提供端返回的关于上述开锁指令的开锁成功信息，则计算发送上述开锁指令后，上述目标服务提供端的实际行驶数据和上述服务请求端的历史行驶数据的相似度；上述目标上报点是目标服务提供端在行驶过程中车轮转速超过预设数值的上报点。

一种可能的实施方式中，计算模块62，包括：

轮速单元623，用于若上述目标服务提供端所对应的目标上报点的数量超过预设数量，且未在第一预设时间内接收到上述目标服务提供端返回的关于上述开锁指令的开锁成功信息，则计算发送上述开锁指令后，上述目标服务提供端的实际行驶数据和上述服务请求端的历史行驶数据的相似度；上述目标上报点是目标服务提供端在行驶过程中车轮转速超过预设数值的上报点。

一种可能的实施方式中，计算模块62，包括：

查询单元624，用于若未在第二预设时间内产生使用上述目标服务提供端或由上述服务请求端发起的服务订单，且未在第一预设时间内接收到上述目标服务提供端返回的关于上述开锁指令的开锁成功信息，则计算发送上述开锁指令后，上述目标服务提供端的实际行驶数据和上述服务请求端的历史行驶数据的相似度；所述第二预设时间的时间长度大于或等于所述第一预设时间的时间长度。

一种可能的实施方式中，计算模块62，还包括：

轨迹单元625，用于计算发送上述开锁指令后，上述目标服务提供端的实际行驶轨迹和每个上述服务请求端的历史行驶轨迹的轨迹相似度；将上述轨迹相似度中数值最大的目标轨迹相似度作为上述目标服务提供端的实际行驶数据和上述服务请求端的历史行驶数据的相似度。

一种可能的实施方式中，计算模块62还包括组合单元626，修复模块63包括组合修复单元631：其中，

组合单元626，用于计算发送所述开锁指令后，所述目标服务提供端的实际行驶轨迹和每个所述服务请求端的历史行驶轨迹的轨迹相似度；计算发送所述开锁指令后，所述目标服务提供端上设置的座椅重力感应装置采集的当前座椅重力值和所述服务请求端的历史座椅重力值的重力相似度；

组合修复单元627，用于根据上述轨迹相似度中数值最大的目标轨迹相似度与上述重力相似度，确定是否对上述使用请求所对应的服务订单进行修复。

一种可能的实施方式中，修复模块63，还包括：

第一修复单元632，用于若上述轨迹相似度中数值最大的目标轨迹相似度高于第一阈值，且上述重力相似度高于第二阈值，则对上述使用请求所对应的服务订单进行修复。

一种可能的实施方式中，修复模块63，还包括：

第二修复单元633，用于若上述轨迹相似度中数值最大的目标轨迹相似度低于第一阈值，且上述重力相似度高于第二阈值，则向上述服务请求端发送订单确认消息；根据接收到上述服务请求端对上述订单确认消息的反馈消息，确定是否对上述使用请求所对应的服务订单进行修复。

一种可能的实施方式中，计算模块62，还包括：

重力单元628，用于计算发送上述开锁指令后，上述目标服务提供端上设置的座椅重力感应装置采集的当前座椅重力值和上述服务请求端的历史座椅重力值的重力相似度；将上述重力相似度作为上述目标服务提供端的实际行驶数据和上述服务请求端的历史行驶数据的相似度。

关于装置中的各模块的处理流程、以及各模块之间的交互流程的描述可以参照上述方法实施例中的相关说明，这里不再详述。

本申请实施例还提供了一种计算机设备70，如图4所示，为本申请实施例提供的计算机设备70结构示意图，包括：处理器71、存储器72、和总线73。所述存储器72存储有所述处理器71可执行的机器可读指令(比如，图3中的装置中通信模块、计算模块、修复模块对应的执行指令等)，当计算机设备70运行时，所述处理器71与所述存储器72之间通过总线73通信，所述机器可读指令被所述处理器71执行时执行上述订单修复方法及其可能的实施方式对应的处理。

本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述订单修复方法的步骤。

具体地，该存储介质能够为通用的存储介质，如移动磁盘、硬盘等，该存储介质上的计算机程序被运行时，能够执行上述订单修复方法，从而如何判断是否修复超时订单的问题，进而达到提高了服务订单的完整度，从而保证了订单系统的稳定。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统和装置的具体工作过程，可以参考方法实施例中的对应过程，本申请中不再赘述。在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、rom、ram、磁碟或者光盘等各种可以存储程序代码的介质。

以上仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。