CN114742336A - 订单处理方法、打车调度方法、装置、设备、介质及产品 - Google Patents

Abstract

本申请实施例涉及一种订单处理方法、打车调度方法、装置、设备、介质及产品，其中，第一服务器上聚合有多个第二服务器提供的打车服务，当第一服务器接收到多个第二服务器中的某个第二服务器发送的订单取消通知之后，第一服务器自动将打车订单重新派发给多个第二服务器中的至少一个目标第二服务器，从而无需用户手动下单，即可实现对被取消订单的重新派单，节省了用户操作，提升了用户体验。

Description

订单处理方法、打车调度方法、装置、设备、介质及产品

技术领域

本申请实施例涉及订单处理技术领域，尤其涉及一种订单处理方法、打车调度方法、装置、设备、介质及产品。

背景技术

聚合打车平台是一种包含多个网约车服务平台提供的多种打车服务的平台。用户通过聚合打车平台可以同时呼叫多个网约车服务平台提供的多种打车服务，从而缩短接单时间。但是，相关技术存在网约车司机接单后，又取消订单的情况，用户体验较差。

发明内容

为了解决上述技术问题或者至少部分地解决上述技术问题，本申请实施例提供了一种订单处理方法、打车调度方法、装置、设备、介质及产品。

本申请实施例的第一方面提供了一种订单处理方法，所述方法适用于第一服务器，所述第一服务器上聚合有多个第二服务器提供的打车服务，所述方法包括：

接收所述第二服务器发送的订单取消通知，所述订单取消通知是在所述第二服务器提供的司机资源取消所述第一服务器派发的打车订单后发出的；

将所述打车订单重新派发给所述多个第二服务器中的至少一个目标第二服务器。

本申请实施例的第二方面提供了一种订单处理方法，所述方法包括：

向第一服务器发送订单请求，所述订单请求中包括打车订单的起始位置和终点位置，所述第一服务器上聚合有多个第二服务器提供的打车服务；

响应于所述打车订单被所述第二服务器提供的司机资源承接，接收所述第二服务器反馈的接单信息；

响应于所述司机资源取消所述打车订单，接收所述第一服务器在将所述打车订单重新派发给所述多个第二服务器中的至少一个目标第二服务器之后反馈的提示信息。

本申请实施例的第三方面提供了一种打车调度方法，所述方法适用于第一服务器，所述第一服务器上聚合有多个第二服务器提供的打车服务，所述方法包括：

向所述多个第二服务器发送调度请求，所述调度请求中包括待派发的打车订单的起始位置的信息；

接收各第二服务器上报的所述起始位置周围预设范围内处于接单状态的司机数量；

基于所述司机数量，将所述打车订单派发给所述多个第二服务器中的至少一个目标第二服务器。

本申请实施例的第四方面提供了一种打车调度方法，所述方法适用于第一服务器，所述第一服务器上聚合有多个第二服务器提供的打车服务，所述方法包括：

获取各第二服务器在预设时间内取消订单的次数；

基于所述次数，将待派发的打车订单派发给所述多个第二服务器中的至少一个目标第二服务器。

本申请实施例的第五方面提供了一种订单处理装置，所述装置配置于第一服务器中，所述第一服务器上聚合有多个第二服务器提供的打车服务，所述订单处理装置包括：

接收模块，用于接收第二服务器发送的订单取消通知，所述订单取消通知是在所述第二服务器提供的司机资源取消所述第一服务器派发的打车订单后发出的；

订单重新派发模块，用于将所述打车订单重新派发给所述多个第二服务器中的至少一个目标第二服务器。

本申请实施例的第六方面提供了一种订单处理装置，包括：

发送模块，用于向第一服务器发送订单请求，所述订单请求中包括打车订单的起始位置和终点位置，所述第一服务器上聚合有多个第二服务器提供的打车服务；

第一接收模块，用于在所述打车订单被所述第二服务器提供的司机资源承接时，接收所述第一服务器反馈的接单信息；

第二接收模块，用于在所述司机资源取消所述打车订单时，接收所述第一服务器在将所述打车订单重新派发给所述多个第二服务器中的至少一个目标第二服务器之后反馈的提示信息。

本申请实施例的第七方面提供了一种打车调度装置，所述装置配置于第一服务器，所述第一服务器上聚合有多个第二服务器提供的打车服务，所述打车调度装置包括：

发送模块，用于向所述多个第二服务器发送调度请求，所述调度请求中包括待派发的打车订单的起始位置的信息；

接收模块，用于接收各第二服务器上报的所述起始位置周围预设范围内处于接单状态的司机数量；

订单派发模块，用于基于所述司机数量，将所述打车订单派发给所述多个第二服务器中的至少一个目标第二服务器。

本申请实施例的第八方面提供了一种打车调度装置，所述装置配置于第一服务器，所述第一服务器上聚合有多个第二服务器提供的打车服务，所述打车调度装置包括：

获取模块，用于获取各第二服务器在预设时间内取消订单的次数；

订单派发模块，用于基于所述次数，将待派发的打车订单派发给所述多个第二服务器中的至少一个目标第二服务器。

本申请实施例的第九方面提供了一种服务器，包括存储器和处理器，其中，所述存储器中存储有计算机程序，当所述计算机程序被所述处理器执行时，实现如上述第一方面、第三方面、第四方面中任一方面的方法。

本申请实施例的第十方面提供了一种终端设备，包括：存储器和处理器，其中，所述存储器中存储有计算机程序，当所述计算机程序被所述处理器执行时，实现上述第二方面所述的方法。

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

本申请实施例的第十二方面提供了一种计算机程序产品，该计算机程序产品包括：计算机程序，该计算机程序存储在计算机可读存储介质中，处理器从该计算机可读存储介质中读取并执行该计算机程序，当该计算机程序被上述处理器执行时，可以实现上述第一方面至第四方面中的任一方面的方法。

本申请实施例提供的技术方案与现有技术相比具有如下优点：

本申请实施例中所称的第一服务器上聚合有多个第二服务器提供的打车服务，当第一服务器接收到多个第二服务器中的某个第二服务器发送的订单取消通知之后，第一服务器能够自动将打车订单重新派发给多个第二服务器中的至少一个目标第二服务器，从而无需用户手动下单，即可实现对被取消订单的重新派单，节省了用户操作，提升了用户体验。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

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

图1是相关技术提供的一种打车场景的示意图本申请；

图2是本申请实施例提供的一种订单处理方法的流程图；

图3是本申请实施例提供的一种打车调度方法的流程图；

图4是本申请实施例提供的又一种打车调度方法的流程图；

图5是本申请实施例提供的又一种打车调度方法的流程图；

图6是本申请实施例提供的又一种打车调度方法的流程图；

图7是本申请实施例提供的一种订单处理流程的示意图；

图8是本申请实施例提供的一种订单处理装置的结构示意图；

图9是本申请实施例提供的又一种订单处理装置的结构示意图；

图10是本申请实施例提供的又一种打车调度装置的结构示意图；

图11是本申请实施例提供的又一种打车调度装置的结构示意图；

图12是本申请实施例中的一种服务器的结构示意图本申请。

具体实施方式

为了能够更清楚地理解本申请的上述目的、特征和优点，下面将对本申请的方案进行进一步描述。需要说明的是，在不冲突的情况下，本申请的实施例及实施例中的特征可以相互组合。

在下面的描述中阐述了很多具体细节以便于充分理解本申请，但本申请还可以采用其他不同于在此描述的方式来实施；显然，说明书中的实施例只是本申请的一部分实施例，而不是全部的实施例。

图1是相关技术提供的一种打车场景的示意图。在图1所示的场景中，终端设备上安装有目标打车软件，用户可以通过终端设备上的目标打车软件向第一服务器发起订单请求。第一服务器上聚合有n(n为大于1的整数)个第二服务器(第二服务器可以理解为一种可以提供一种或多种打车服务的服务器，不同的第二服务器提供的打车服务可以不同)提供的多种打车服务。当第一服务器接收到终端设备的订单请求时，第一服务器会将订单请求对应的打车订单派发给提供打车服务的n个第二服务器，从而使得各第二服务器将打车订单派发给各自平台上注册的司机终端。在经过各司机抢单后，最先抢到打车订单的司机，承接打车订单。但是，如果司机接单后又取消订单，则需要用户手动重新下单，操作较为繁琐，用户体验不佳。

针对相关技术存在的上述缺陷，本申请实施例提供了一种新的订单处理方案。该方案通过在第二服务器提供的司机资源取消了第一服务器派发的打车订单之后，重新将打车订单派发到至少一个目标第二服务器上，以实现打车订单的自动重新派发，从而减少了用户的操作，提高了用户体验。比如，在图1所示的场景中，如果第二服务器1的司机资源(或者也可以理解为司机)承接了终端设备的打车订单后，又取消了订单，则第一服务器在接收到第二服务器1发送的订单取消通知之后，重新将订单派发给n个第二服务器中的至少一个目标第二服务器上，从而使得接收到打车订单的目标第二服务器，重新将订单派发到各自平台的司机终端上进行抢单，最先抢到订单的司机资源，将承接该订单。

本申请为了更好的理解本申请实施例的发明构思，下面结合示例性的实施例对本申请实施例的技术方案进行说明。

图2是本申请实施例提供的一种订单处理方法的流程图，该方法适用于第一服务器，第一服务器上聚合有多个第二服务器提供的打车服务。如图2所示，本实施例提供的方法包括如下步骤：

步骤201、接收第二服务器发送的订单取消通知。

其中，第一服务器可以理解为聚合有多个第二服务器提供的多种打车服务的服务器。第一服务器面向用户提供服务，具体过程包括接收用户的订单请求，将订单请求对应的打车订单派发给多个第二服务器，以使各第二服务器将打车订单派发给各自平台上的司机终端进行竞争接单，其中，最先接单的司机终端将承接该打车订单。

第二服务器可以提供一种或多种打车服务。不同的第二服务器提供的打车服务可以不同。

订单取消通知可以理解是在第二服务器提供的司机资源取消第一服务器派发的打车订单后发出的，即如果第二服务器提供的司机资源承接了第一服务器派发的订单之后又取消了订单，则第二服务器会向第一服务器发送订单取消通知。本实施例中，订单取消通知中示例性的可以包括被取消的打车订单的信息。

步骤202、将打车订单重新派发给多个第二服务器中的至少一个目标第二服务器。

本申请实施例所称的目标第二服务器提供的打车服务聚合在第一服务器上。目标第二服务器可以从多个第二服务器中随机确定，也可以根据预设策略确定，本实施例不做具体限定。

例如，在一种可行的实施方式中，打车订单中可以包括订单的起始位置的信息，第一服务器在重新派发打车订单时，可以获取各第二服务器在起始位置周围预设范围内的订单承接能力；将订单承接能力大于预设阈值的第二服务器确定为目标第二服务器。

其中，订单的起始位置的信息可以理解为触发该订单的用户选择的行程的起始点的信息。由于起始位置周围预设范围内的司机为距离起始位置距离较近的司机，因此他们较为容易承接订单，因此，各第二服务器在起始位置周围预设范围内的订单承接能力可以作为重新派发订单时的参考。

订单承接能力可以理解为衡量各第二服务器提供的司机资源能否快速承接订单的评价标准，例如，在一个示例中，第二服务器在起始位置周围预设范围内的排队订单中排在最后一个订单的预计等待时间可以确定为第二服务器对应的订单承接能力，当然这里仅为示例说明，并不是唯一限定，例如，在其他实施例中也可以根据第二服务器在起始位置周围预设范围内可承接订单的司机数量(或者也可以理解为处于接单状态的司机数量)来衡量第二服务器在起始位置周围预设范围内的订单承接能力，其中，可承接订单的司机数量与订单承接能力正相关。或者在另一些实施例中还可以利用第二服务器在预设时间内取消订单的次数来衡量第二服务器的订单承接能力，其中预设时间内取消订单的次数与订单承接能力成负相关。

在一些实施例中，第一服务器在获取到各第二服务器在起始位置周围预设范围内的订单承接能力之后，可以将各第二服务器的订单承接能力与预设阈值进行比较，将订单承接能力大于预设阈值的第二服务器确定为目标第二服务器，将打车订单重新派发给目标第二服务器。

在一些实施例中，第一服务器在将打车订单重新派发给至少一个目标第二服务器之后，还可以向产生打车订单的用户终端发送打车订单被重新派发的提示消息。其中，提示消息可以理解为用于提示用户当前打车订单虽然被取消但是被重新派发的消息，具体消息内容不限，可以根据实际情况设置。

通过重新派单之后，向产生打车订单的用户终端发送提示消息，能够帮助用户充分了解当前打车订单的派发情况，提升用户体验。

本申请实施例中所称的第一服务器上聚合有多个第二服务器提供的打车服务，当第一服务器接收到多个第二服务器中的某个第二服务器发送的订单取消通知之后，能够自动将打车订单重新派发给多个第二服务器中的至少一个目标第二服务器，从而无需用户手动下单，即可实现对被取消订单的重新派单，节省了用户操作，提升了用户体验。

示例性的，图3是本申请实施例提供的一种打车调度方法的流程图，如图3所示，在一种示例性的实施方式中，第一服务器在接收到订单取消通知之后，可以基于如下方法对打车订单进行调度：

步骤301、获取各第二服务器在预设时间内取消订单的次数。

在一些实施方式中，第一服务器可以在接收到第二服务器的订单取消通知时，对第二服务器取消订单的次数进行记录和更新。

在本申请实施例中，第一服务器记录第二服务器取消订单的次数的方式可以有多种。比如在一种可行的记录方式中，第一服务器记录订单取消通知以及接收到订单取消通知的时间，基于各订单取消通知对应的时间来统计得到第二服务器在预设时间内取消订单的次数。这种方式有助于对第二服务器在不同时间段内的订单承接情况进行分析。再比如，在另一种可行的记录方式中，第一服务器仅对第二服务器预设时间内的订单取消次数进行计数，在超过预设时间后对预设时间内的记数进行清零并开始下一轮预设时间的计数。这样有助于节省存储空间，提高订单取消次数的查询效率。

步骤302、根据取消订单的次数，将打车订单重新派发给至少一个目标第二服务器。

在一些实施方式中，可以示例性的对各第二服务器在预设时间内的订单取消次数按照从小到达的顺序进行排序，并将对应排序高于第二预设排序的第二服务器确定为目标第二服务器，进而将打车订单重新派发给目标第二服务器。其中，第二预设排序的具体取值可以根据需要进行设置，而不必局限于某一特定的取值。

本申请实施例通过将打车订单重新派发给取消订单次数较少的目标第二服务器，能够防止打车订单被多次取消，进而保证用户的打车订单能够被迅速承接并履行，从而提高了用户体验。

示例性的，图4是本申请实施例提供的又一种打车调度方法的流程图，如图4所示，在一种示例性的实施方式中，第一服务器在接收到订单取消通知之后，可以基于如下方法对打车订单进行重新调度：

步骤401、针对任一第二服务器，获取第二服务器在起始位置周围预设范围内的排队订单数量和第二服务器在预设时间内取消订单的次数。

其中，排队订单数量是指第二服务器中正在等待接单的打车订单的数量。取消订单是指第二服务器提供的司机资源主动承接第一服务器派发的打车订单后，又取消的打车订单。预设时间可以根据实际需要设置，例如预设时间可以为1天。

由于排队订单数据和取消订单的次数可以影响第二服务器派发订单的效率，因此在本实施例中，可以向第二服务器发送数据获取请求，获取第二服务器在打车订单的起始位置周围预设范围内的排队订单数量，以及在预设时间内取消订单的次数，并基于排队订单数量和取消订单的次数来确定订单重新派发给哪些第二服务器(即订单重新派发的对象，该对象即为目标第二服务器)，其中，基于排队订单数量和取消订单的次数来确定重新派发的对象的方法在本实施例的后面部分进一步说明，这里不多做赘述。

步骤402、基于各第二服务器的排队订单数量和取消订单的次数确定订单重新派发的对象。

例如，在本申请实施例的一种示例性的实施方式中，可以分别对每个第二服务器的排队订单数量和取消订单的次进行加权求和处理，将加权求和结果小于预设阈值的第二服务器确定为订单重新派发的对象，即目标第二服务器。其中，上述用于对排队订单数量和取消订单的次数进行加权求和的权重可以相同，也可以不同。第一服务器在获取到第二服务器的排队订单数量和取消订单的次数之后，可以分别计算排队订单数量与其对应的权重的第一乘积、取消订单的次数与其对应的权重的第二乘积，并确定上述第一乘积和第二乘积之和，如果第一乘积和第二乘积之和小于预设阈值，则确定该第二服务器为订单重新派发的对象，否则不将打车订单重新派发给该第二服务器。

步骤403、将打车订单重新派发给所述对象。

由于第二服务器排队订单的数量和取消订单的次数越高，第二服务器派发订单的能力越低，也即越不容易将订单派发成功，或者订单容易被再次取消，因此将排队订单数量和取消订单的次数的进行加权求和处理，根据加权求和结果判断是否将打车订单重新派发给该第二服务器，能够提高订单重新派发的成功率，提高用户体验。

示例性的，图5是本申请实施例提供的又一种打车调度方法的流程图，如图5所示，在一种示例性的实施方式中，第一服务器在接收到订单取消通知之后，可以基于如下方法对打车订单进行重新调度：

步骤501、向多个第二服务器发送调度请求，调度请求中包括打车订单的起始位置的信息。

步骤502、接收各第二服务器上报的所述起始位置周围预设范围内处于接单状态的司机数量。

步骤503、根据起始位置周围预设范围内处于接单状态的司机数量，将打车订单重新派发给至少一个目标第二服务器。

在本申请实施例的一种实施方式中可以将第二服务器位于打车订单起始位置周围预设范围内的，且处于接单状态的司机数量作为衡量第二服务器订单承接能力的标准。第一服务器接收到订单取消通知时，可以通过发送调度请求的方式，从各第二服务器上获取各第二服务器在打车订单起始位置周围预设范围内处于接单状态的司机数量。并按照由大到小的顺序对各第二服务器对应的上述司机数量进行排序，假设第一预设排序为M(M为大于或等于1的整数)，则对应排序前M位，包括M位的第二服务器，确定为目标第二服务器，将打车订单重新派发给目标第二服务器。

由于第二服务器位于起始位置周围预设范围内的，且处于接单状态的司机数量，能够一定程度上的反应第二服务器在该起始位置周围的订单承接能力，因此，将打车订单重新派发给上述司机数量较大的目标第二服务器，能够提高订单重派的成功率，提升用户体验。

示例性的，图6是本申请实施例提供的又一种打车调度方法的流程图，如图6所示，在一种示例性的实施方式中，第一服务器在接收到订单取消通知之后，可以基于如下方法对打车订单进行重新调度：

步骤601、针对任一第二服务器，获取第二服务器在订单起始位置周围预设范围内处于接单状态的司机数量和排队订单数量。

步骤602、根据订单起始位置周围预设范围内处于接单状态的司机数量和排队订单数量，将打车订单重新派发给至少一个目标第二服务器。

在本申请实施例的一种实施方式中，可以将第二服务器在订单起始位置周围预设范围内处于接单状态的司机数量占第二服务器在订单起始位置周围预设范围内的排队订单数量的比例值，作为衡量第二服务器订单承接能力的标准，其中，该比例值越大说明第二服务器在该范围内的订单被承接的速率越高，因此，可以将上述比例值大于预设阈值的第二服务器，确定为目标第二服务器。通过将打车订单重新派发给上述比例值大于预设阈值的目标第二服务器，能够缩短接单时间，提高用户体验。

示例性的，图7是本申请实施例提供的一种订单处理流程的示意图，如图7所示，订单处理的整体过程可以包括：

步骤701、向第一服务器发送订单请求。

其中，第一服务器是指聚合有多个第二服务器的打车服务的服务器。参见图1所示的场景，在本申请实施例中用户可以通过终端设备上搭载的目标打车软件向第一服务器发送订单请求。其中，该目标打车软件可以向用户提供同时向多个车型下单的选项，用户在触发该选项后，目标打车软件向第一服务器发送订单请求，订单请求中，包括用户在目标打车软件上配置的打车订单的起始位置和终点位置。

步骤702、第一服务器根据订单请求，将包含起始位置和终点位置的打车订单发送给多个第二服务器，以使各第二服务器将打车订单派发到各自平台的司机客户端上。

步骤703、响应于打车订单被第二服务器的司机资源承接，接收第一服务器反馈的接单信息。

其中，接单信息包括但不局限于如下中的至少一种信息：接单的打车平台的信息、接单司机的信息、接单司机的车辆信息、预计到达起始位置的时间信息等。

步骤704、响应于所述司机资源取消所述打车订单，接收所述第一服务器在将打车订单重新派发给至少一个目标第二服务器之后反馈的提示信息。

示例的，在本申请实施例的一些实施方式中，第一服务器在接收到某个第二服务器的订单取消通知后，可以根据多个第二服务器中每个第二服务器在订单起始位置周围预设范围内处于接单状态的司机数量，并将司机数量的排序高于第一预设排序的第二服务器确定为目标第二服务器。或者也可以根据各第二服务器在预设时间内取消订单的次数，按照取消订单的次数由小到大的顺序，将取消订单次数的排序高于第二预设排序的第二服务器确定为目标第二服务器。

本申请实施例所称的提示信息，用于提示用户打车订单被取消并重新完成派发，示例的，该提示信息中至少还可以包括重新接单的打车平台的信息、接单司机的信息、接单司机的车辆信息、预计到达起始位置的时间信息中的至少一种。

本申请实施例的订单处理流程和有益效果可以参见图2-图6的实施例，在这里不再赘述。

本申请图8是本申请实施例提供的一种订单处理装置的结构示意图,该订单处理装置可以被理解为上述第一服务器或者上述第一服务器的部分功能模块。如图8所示，订单处理装置80包括：

接收模块81，用于接收所述第二服务器发送的订单取消通知，所述订单取消通知是在所述第二服务器提供的司机资源取消所述第一服务器派发的打车订单后发出的；

订单重新派发模块82，用于将所述打车订单重新派发给所述多个第二服务器中的至少一个目标第二服务器。

在一种实施方式中，所述打车订单中包括订单的起始位置的信息；

所述订单重新派发模块82可以用于：

向所述多个第二服务器发送调度请求，所述调度请求中包括所述起始位置的信息；

接收各第二服务器上报的所述起始位置周围预设范围内处于接单状态的司机数量；

按照所述司机数量由大到小的顺序，将排序高于第一预设排序的第二服务器确定为目标第二服务器。

在一种实施方式中，订单重新派发模块82可以用于：

获取各第二服务器在预设时间内取消订单的次数；

按照所述次数由小到大的顺序，将所述次数的排序高于第二预设排序的第二服务器确定为目标第二服务器。

在一种实施方式中，所述装置还包括提示模块，用于：在将所述打车订单重新派发给所述多个第二服务器中的至少一个目标第二服务器之后，

向产生所述打车订单的用户终端发送所述打车订单被重新派发的提示消息。

本实施例提供的装置能够执行上述图2-图6中任一实施例的方法，其执行方式和有益效果类似，在这里不再赘述。

图9是本申请实施例提供的又一种订单处理装置的结构示意图，该订单处理装置可以被具体为上述实施例中的终端设备或者上述终端设备的部分功能模块，如图9所示，订单处理装置90，包括：

发送模块91，用于向第一服务器发送订单请求，所述订单请求中包括打车订单的起始位置和终点位置，所述第一服务器上聚合有多个第二服务器提供的打车服务；

第一接收模块92，用于在所述打车订单被所述第二服务器提供的司机资源承接时，接收所述第一服务器反馈的接单信息；

第二接收模块93，用于在所述司机资源取消所述打车订单时，接收所述第一服务器在将所述打车订单重新派发给所述多个第二服务器中的至少一个目标第二服务器之后反馈的提示信息。

在一种实施方式中，所述目标第二服务器是指预设时间内取消订单次数的排序高于第二预设排序的第二服务器，其中，所述次数按照由小到大的顺序排序。

在一种实施方式中，所述目标第二服务器是指司机数量的排序高于第一预设排序的第二服务器，其中，所述司机数量是指所述起始位置周围预设范围内处于接单状态的司机数量，所述司机数量按照由大到小的顺序排序。

本实施例提供的装置能够执行上述图7实施例的方法，其执行方式和有益效果类似，在这里不再赘述。

图10是本申请实施例提供的又一种打车调度装置的结构示意图，该打车调度装置可以被具体为上述实施例中的第一服务器或者上述第一服务器的部分功能模块，如图10所示，打车调度装置1000，包括：

发送模块1001，用于向所述多个第二服务器发送调度请求，所述调度请求中包括待派发的打车订单的起始位置的信息；

接收模块1002，用于接收各第二服务器上报的所述起始位置周围预设范围内处于接单状态的司机数量；

订单派发模块1003，用于基于所述司机数量，将所述打车订单派发给所述多个第二服务器中的至少一个目标第二服务器。

本申请实施例提供的装置其执行方式和有意效果与图5和图6实施例类似，在这里不再赘述。

图11是本申请实施例提供的又一种打车调度装置的结构示意图，该打车调度装置可以被具体为上述实施例中的第一服务器或者上述第一服务器的部分功能模块，如图11所示，打车调度装置1100，包括：

获取模块1101，用于获取各第二服务器在预设时间内取消订单的次数；

订单派发模块1102，用于基于所述次数，将待派发的打车订单派发给所述多个第二服务器中的至少一个目标第二服务器。

本申请实施例提供的装置其执行方式和有意效果与图3和图4实施例类似，在这里不再赘述。

本申请实施例还提供一种服务器，该服务器包括处理器和存储器，其中，所述存储器中存储有计算机程序，当所述计算机程序被所述处理器执行时可以实现上述图2-图6中任一实施例的方法。

示例的，图12是本申请实施例中的一种服务器的结构示意图。下面具体参考图12，其示出了适于用来实现本申请实施例中的服务器1200的结构示意图。本申请实施例中的服务器1200可以理解为具有处理和计算能力的计算机、服务器或服务器集群。图12示出的服务器仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图12所示，服务器1200可以包括处理装置(例如中央处理器、图形处理器等)1201，其可以根据存储在只读存储器(ROM)1202中的程序或者从存储装置1208加载到随机访问存储器(RAM)1203中的程序而执行各种适当的动作和处理。在RAM 1203中，还存储有服务器1200操作所需的各种程序和数据。处理装置1201、ROM 1202以及RAM 1203通过总线1204彼此相连。输入/输出(I/O)接口1205也连接至总线1204。

通常，以下装置可以连接至I/O接口1205：包括例如触摸屏、触摸板、键盘、鼠标、摄像头、麦克风、加速度计、陀螺仪等的输入装置1206；包括例如液晶显示器(LCD)、扬声器、振动器等的输出装置12012；包括例如磁带、硬盘等的存储装置1208；以及通信装置1209。通信装置1209可以允许服务器1200与其他设备进行无线或有线通信以交换数据。虽然图12示出了具有各种装置的服务器1200，但是应理解的是，并不要求实施或具备所有示出的装置。可以替代地实施或具备更多或更少的装置。

特别地，根据本申请的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在非暂态计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信装置1209从网络上被下载和安装，或者从存储装置1208被安装，或者从ROM 1202被安装。在该计算机程序被处理装置1201执行时，执行本申请实施例的方法中限定的上述功能。

需要说明的是，本申请上述的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读信号介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：电线、光缆、RF(射频)等等，或者上述的任意合适的组合。

在一些实施方式中，客户端、服务器可以利用诸如HTTP(HyperText TransferProtocol，超文本传输协议)之类的任何当前已知或未来研发的网络协议进行通信，并且可以与任意形式或介质的数字数据通信(例如，通信网络)互连。通信网络的示例包括局域网(“LAN”)，广域网(“WAN”)，网际网(例如，互联网)以及端对端网络(例如，ad hoc端对端网络)，以及任何当前已知或未来研发的网络。

上述计算机可读介质可以是上述服务器中所包含的；也可以是单独存在，而未装配入该服务器中。

上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被该服务器执行时，使得该服务器：接收所述第二服务器发送的订单取消通知，所述订单取消通知是在所述第二服务器提供的司机资源取消所述第一服务器派发的打车订单后发出的；将所述打车订单重新派发给所述多个第二服务器中的至少一个目标第二服务器。

可以以一种或多种程序设计语言或其组合来编写用于执行本申请的操作的计算机程序代码，上述程序设计语言包括但不限于面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。

附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现。其中，单元的名称在某种情况下并不构成对该单元本身的限定。

本文中以上描述的功能可以至少部分地由一个或多个硬件逻辑部件来执行。例如，非限制性地，可以使用的示范类型的硬件逻辑部件包括：现场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、片上系统(SOC)、复杂可编程逻辑设备(CPLD)等等。

在本申请的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

本申请实施例还提供一种计算机可读存储介质，所述存储介质中存储有计算机程序，当所述计算机程序被处理器执行时可以实现上述图2-图7中任一实施例的方法，其执行方式和有益效果类似，在这里不再赘述。

本申请实施例还提供一种计算机程序产品，该计算机程序产品包括：计算机程序，所述计算机程序存储在计算机可读存储介质中，处理器从所述计算机可读存储介质中读取并执行所述计算机程序，当所述计算机程序被所述处理器执行时可以实现上述图2-图7中任一实施例的方法，其执行方式和有益效果类似，在这里不再赘述。

本申请实施例还提供一种终端设备，该终端设备包括存储器和处理器，其中，所述存储器中存储有计算机程序，当所述计算机程序被所述处理器执行时，实现如图7实施例所述的方法。

需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述仅是本申请的具体实施方式，使本领域技术人员能够理解或实现本申请。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所述的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (17)

1.一种订单处理方法，其特征在于，所述方法适用于第一服务器，所述第一服务器上聚合有多个第二服务器提供的打车服务，所述方法包括：

接收所述第二服务器发送的订单取消通知，所述订单取消通知是在所述第二服务器提供的司机资源取消所述第一服务器派发的打车订单后发出的；

将所述打车订单重新派发给所述多个第二服务器中的至少一个目标第二服务器。

2.根据权利要求1所述的方法，其特征在于，所述打车订单中包括订单的起始位置的信息；

所述将所述打车订单重新派发给所述多个第二服务器中的至少一个目标第二服务器，包括：

向所述多个第二服务器发送调度请求，所述调度请求中包括所述起始位置的信息；

接收各第二服务器上报的所述起始位置周围预设范围内处于接单状态的司机数量；

按照所述司机数量由大到小的顺序，将排序高于第一预设排序的第二服务器确定为目标第二服务器。

3.根据权利要求1所述的方法，其特征在于，所述将所述打车订单重新派发给所述多个第二服务器中的至少一个目标第二服务器，包括：

获取各第二服务器在预设时间内取消订单的次数；

按照所述次数由小到大的顺序，将所述次数的排序高于第二预设排序的第二服务器确定为目标第二服务器。

4.根据权利要求1-3中任一项所述的方法，其特征在于，所述将所述打车订单重新派发给所述多个第二服务器中的至少一个目标第二服务器之后，所述方法还包括：

向产生所述打车订单的用户终端发送所述打车订单被重新派发的提示消息。

5.一种订单处理方法，其特征在于，包括：

向第一服务器发送订单请求，所述订单请求中包括打车订单的起始位置和终点位置，所述第一服务器上聚合有多个第二服务器提供的打车服务；

响应于所述打车订单被所述第二服务器提供的司机资源承接，接收所述第二服务器反馈的接单信息；

响应于所述司机资源取消所述打车订单，接收所述第一服务器在将所述打车订单重新派发给所述多个第二服务器中的至少一个目标第二服务器之后反馈的提示信息。

6.根据权利要求5所述的方法，其特征在于，所述目标第二服务器是指司机数量的排序高于第一预设排序的第二服务器，其中，所述司机数量是指所述起始位置周围预设范围内处于接单状态的司机数量，所述司机数量按照由大到小的顺序排序。

7.根据权利要求5所述的方法，其特征在于，所述目标第二服务器是指预设时间内取消订单次数的排序高于第二预设排序的第二服务器，其中，所述次数按照由小到大的顺序排序。

8.一种打车调度方法，其特征在于，所述方法适用于第一服务器，所述第一服务器上聚合有多个第二服务器提供的打车服务，所述方法包括：

向所述多个第二服务器发送调度请求，所述调度请求中包括待派发的打车订单的起始位置的信息；

接收各第二服务器上报的所述起始位置周围预设范围内处于接单状态的司机数量；

基于所述司机数量，将所述打车订单派发给所述多个第二服务器中的至少一个目标第二服务器。

9.一种打车调度方法，其特征在于，所述方法适用于第一服务器，所述第一服务器上聚合有多个第二服务器提供的打车服务，所述方法包括：

获取各第二服务器在预设时间内取消订单的次数；

基于所述次数，将待派发的打车订单派发给所述多个第二服务器中的至少一个目标第二服务器。

10.一种订单处理装置，其特征在于，所述装置配置于第一服务器中，所述第一服务器上聚合有多个第二服务器提供的打车服务，所述订单处理装置包括：

接收模块，用于接收第二服务器发送的订单取消通知，所述订单取消通知是在所述第二服务器提供的司机资源取消所述第一服务器派发的打车订单后发出的；

订单重新派发模块，用于将所述打车订单重新派发给所述多个第二服务器中的至少一个目标第二服务器。

11.一种订单处理装置，其特征在于，包括：

发送模块，用于向第一服务器发送订单请求，所述订单请求中包括打车订单的起始位置和终点位置，所述第一服务器上聚合有多个第二服务器提供的打车服务；

第一接收模块，用于在所述打车订单被所述第二服务器提供的司机资源承接时，接收所述第一服务器反馈的接单信息；

第二接收模块，用于在所述司机资源取消所述打车订单时，接收所述第一服务器在将所述打车订单重新派发给所述多个第二服务器中的至少一个目标第二服务器之后反馈的提示信息。

12.一种打车调度装置，其特征在于，所述装置配置于第一服务器，所述第一服务器上聚合有多个第二服务器提供的打车服务，所述打车调度装置包括：

发送模块，用于向所述多个第二服务器发送调度请求，所述调度请求中包括待派发的打车订单的起始位置的信息；

接收模块，用于接收各第二服务器上报的所述起始位置周围预设范围内处于接单状态的司机数量；

订单派发模块，用于基于所述司机数量，将所述打车订单派发给所述多个第二服务器中的至少一个目标第二服务器。

13.一种打车调度装置，其特征在于，所述装置配置于第一服务器，所述第一服务器上聚合有多个第二服务器提供的打车服务，所述打车调度装置包括：

获取模块，用于获取各第二服务器在预设时间内取消订单的次数；

订单派发模块，用于基于所述次数，将待派发的打车订单派发给所述多个第二服务器中的至少一个目标第二服务器。

14.一种服务器，其特征在于，包括：

存储器和处理器，其中，所述存储器中存储有计算机程序，当所述计算机程序被所述处理器执行时，实现如权利要求1-4或8-9中任一项所述的方法。

15.一种终端设备，其特征在于，包括：存储器和处理器，其中，所述存储器中存储有计算机程序，当所述计算机程序被所述处理器执行时，实现如权利要求5-7中任一项所述的方法。

16.一种计算机可读存储介质，其特征在于，所述存储介质中存储有计算机程序，当所述计算机程序被处理器执行时，实现如权利要求1-9中任一项所述的方法。

17.一种计算机程序产品，该计算机程序产品包括：计算机程序，所述计算机程序存储在计算机可读存储介质中，处理器从所述计算机可读存储介质中读取并执行所述计算机程序，当所述计算机程序被所述处理器执行时，所述处理器执行如权利要求1-9中任一项所述的方法。

Images