连环派单方法、装置、服务器及存储介质与流程

文档序号:20620318发布日期:2020-05-06 20:44阅读:286来源:国知局
连环派单方法、装置、服务器及存储介质与流程

本申请涉及互联网技术领域,具体而言,涉及一种连环派单方法、装置、服务器及存储介质。



背景技术:

网约载具凭借其接驾时间快、价格便宜等优势已经成为了人们出行的首选方式,这就使得使用网约载具的出行人数越来越多,但却导致网约载具的服务提供端已经出现了供不应求的状况。

那么为了提高派单效率,缩短服务请求端等待应答的时长,系统可以采用连环派单的方式实现载具的分配。即服务中载具的服务提供端在即将完成当前订单或者即将到达当前订单的目的地时,系统会选择起点与当前订单的目的地匹配的新订单分派给服务提供端。

但由于实际情况非常复杂,服务提供端或服务请求端可能会因为道路、天气或个人因素的影响,从而导致服务请求端实际下车的地点与当前订单上的目的地不完全相同。因此,若按照当前订单上的目的地作为新订单的起点为服务提供端的出发位置,导致服务提供端接到新服务请求端的路程增加,不利于提升派单效率,甚至会降低派单效率。且路程增加还导致新服务请求端的等待时间变长,服务请求端的使用体验变差。



技术实现要素:

本申请在于提供一种连环派单方法、装置、服务器及存储介质,以有效提高网约载具的利用效率,并提高服务请求端的使用体验。

为了实现上述目的,本申请的实施例通过如下方式实现:

第一方面,本申请实施例提供了一种连环派单方法,所述方法包括:获得服务提供端的当前服务中订单的目的地;基于所述目的地,以及基于目的地与所述目的地相同的历史订单实际到达的目的地,预估所述当前服务中订单实际可能到达的目的地;以所述实际可能到达的目的地为所述服务提供端的位置,为所述服务提供端派送下一个订单。

在本申请实施例中,通过服务提供端在进行当前服务中订单时,可以根据该当前服务中订单的目的地和目的地与该目的地相同的历史订单实际到达的目的地,对该当前服务中订单的实际可能到达目的地进行预估,由于预估出的实际可能到达的目的地为该当前服务中订单的服务请求端最可能到达的位置,那么以实际可能到达的目的地为服务提供端的位置为服务提供端派送下一个订单,使得服务提供端接到下一个服务请求端的路程很近,避免了服务请求端的达到点和下一个订单的起点的接驾距离太远而导致服务提供端接到下一个服务请求端的接驾成本增加的问题,提升了平台的派单效率。且由于服务提供端接到下一个服务请求端的路程很近,还缩短了下一个服务请求端的等待时间,提升了服务请求端的使用体验。

在第一方面的一些可选的实现方式中,所述基于所述目的地,以及基于目的地与所述目的地相同的历史订单实际到达的目的地,预估所述当前服务中订单实际可能到达的目的地,包括:基于所述目的地,判断所述当前服务中订单对应的服务请求端的历史订单中是否有历史订单的目的地与所述目的地相同的m个历史订单,m为正整数;若是,根据所述m个历史订单中n个实际到达的目的地,预估所述当前服务中订单实际可能到达的目的地,n为不大于m的正整数。

在本申请实施例中,在查找到服务请求端的历史订单的目的地与该目的地相同的m个历史订单时,通过采用m个历史订单中实际到达的目的地来预估该当前服务中订单实际可能到达的目的地的方式,不仅便于实施,且以历史数据为依据进行预测,预测的实际目的地的准确度高、可靠性强。

在第一方面的一些可选的实现方式中,所述根据所述m个历史订单中n个实际到达的目的地,预估所述当前服务中订单实际可能到达的目的地,包括:从所述m个历史订单中获得n个实际到达的目的地;根据所述m个历史订单的数量,计算出所述n个实际到达的目的地中每个实际到达的目的地的到达概率;获得所述n个实际到达的目的地中到达概率最大的目的地,确定所述到达概率最大的目的地为预估的所述当前服务中订单实际可能到达的目的地。

在本申请实施例中,通过计算n个实际到达的目的地中每个实际到达的目的地的到达概率,从而将到达概率最大的目的地作为预估的当前服务中订单实际可能到达的目的地,使得预估出的当前服务中订单实际可能到达的目的地确实为最有到达可能性的目的地,提高了预测的当前服务中订单实际可能到达的目的地的准确度和可靠性。

在第一方面的一些可选的实现方式中,所述获得所述n个实际到达的目的地中到达概率最大的目的地,包括:判断所述n个实际到达的目的地中是否有到达概率最大的目的地;若是,获得所述到达概率最大的目的地;若否,将所述n个实际到达的目的地中随机选择出的目的地作为所述到达概率最大的目的地。

在本申请实施例中,通过判断n个实际到达的目的地中是否有到达概率最大的目的地,在判断为是时,以该到达概率最大的目的地作为当前服务中订单实际可能到达的目的地,则在一方面实现了确定出当前服务中订单实际可能到达的目的地的准确性。但在判断为否时,也可以通过从n个实际到达的目的地中随机选择出的目的地作为该当前服务中订单实际可能到达的目的地,那么则在另一方面实现了方案的可靠性,使得不论在何种情况下,均能够预估出当前服务中订单实际可能到达的目的地。

在第一方面的一些可选的实现方式中,在所述基于所述目的地,判断所述当前服务中订单对应的服务请求端的历史订单中是否有历史订单的目的地与所述目的地相同的m个历史订单之后,所述方法还包括:若没有历史订单的目的地与所述目的地相同的m个历史订单,获得其它服务请求端的其它历史订单的目的地与所述目的地相同的p个其它历史订单,p为正整数;根据所述p个其它历史订单中q个实际到达的目的地,预估所述当前服务中订单实际可能到达的目的地,q为不大于p的正整数。

在本申请实施例中,若在该当前服务中订单对应的服务请求端的历史订单中没有目的地与该目的地相同的m个历史订单,即说明该服务请求端是首次去往该目的地。故可以通过其他服务请求端的其它历史订单的目的地与该目的地相同的p个其它历史订单作为参考并进行预估,并通过p个其它历史订单中q个实际到达的目的地而预估出当前服务中订单实际可能到达的目的地,采用其他服务请求端的历史数据为依据进行预测,预测的实际目的地也具有准确度高和可靠性强等优点,且还保证了方案的可靠性,使得不论在何种情况下,均能够预估出当前服务中订单实际可能到达的目的地。

在第一方面的一些可选的实现方式中,所述根据所述p个其它历史订单中q个实际到达的目的地,预估所述当前服务中订单实际可能到达的目的地,包括:从所述p个其它历史订单中获得q个实际到达的目的地;根据所述p个其它历史订单的数量,计算出所述q个实际到达的目的地中每个实际到达的目的地的到达概率;获得所述q个实际到达的目的地中到达概率最大的目的地,确定所述到达概率最大的目的地作为预估的所述当前服务中订单实际可能到达的目的地。

在本申请实施例中,对于该服务请求端首次去往的目的地来说,其他服务请求端的到达目的地该数据具有相当大的参考性。那么通过计算q个实际到达的目的地中每个实际到达的目的地的到达概率,从而将到达概率最大的目的地作为预估的该当前服务中订单实际可能到达的目的地,也使得预估出的当前服务中订单实际可能到达的目的地对该服务请求端来说是非常准确的。实现了该服务请求端没有历史数据作为参考的情况,也能够提高预测的实际可能到达的目的地的准确度和可靠性。

在第一方面的一些可选的实现方式中,在所述基于所述目的地,判断所述当前服务中订单对应的服务请求端的历史订单中是否有历史订单的目的地与所述目的地相同的m个历史订单之后,所述方法还包括:若没有历史订单的目的地与所述目的地相同的m个历史订单,根据预设的所述目的地与预设目的地关联关系,确定出所述预设目的地;确定所述预设目的地为预估的所述当前服务中订单实际可能到达的目的地。

在本申请实施例中,若也在该当前服务中订单对应的服务请求端没有历史订单的目的地与该目的地相同的m个历史订单,即也说明该服务请求端是首次去往该目的地。故也可以通过预设建立该目的地与预设目的地关联关系的方式,根据关联关系确定出预设目的地,并将该预设目的地作为当前服务中订单实际可能到达的目的地。由于预设目的地往往也是根据历史数据预先获得最有可能到达的目的地,因此,采用关联关系的方式,不仅可以准确的预估出当前服务中订单实际可能到达的目的地,还极大的简化了计算量,降低了计算负荷。

在第一方面的一些可选的实现方式中,所述获得服务提供端的当前服务中订单的当前目的地;在确定服务提供端的当前服务中订单的目的地有修改时,将修改后的目的地作为所述服务提供端的目的地。

在本申请实施例中,若服务提供端的当前服务中订单的服务请求端主动修改了目的地,可以将修改后的目的地作为该当前服务中订单的目的地,实现了即使服务请求端主动修改目的地,还是能够以修改为的目的地来预估当前服务中订单实际可能到达的目的地,提高了方案的可靠性,使得不论在何种情况下,均能够预估出目的地。

在第一方面的一些可选的实现方式中,在所述以所述实际可能到达的目的地为所述服务提供端的位置,为所述服务提供端派送下一个订单之后,所述方法还包括:在监测所述当前服务中订单而确定所述当前服务中订单的目的地有修改时,获得所述当前服务中订单的修改后的目的地;基于所述修改后的目的地,以及基于目的地与所述修改后的目的地相同的历史订单实际到达的目的地,预估所述当前服务中订单新的实际可能到达的目的地;以所述新的实际可能到达的目的地为所述服务提供端的位置,为所述服务提供端派送下一个订单。

在本申请实施例中,若当前服务中订单的服务请求端将当前服务中订单的目的地修改。则也可以根据修改后的目的地来重新预估出新的实际可能到达的目的地,并以新的实际可能到达的目的地为服务提供端的位置,为服务提供端派送下一个订单。其实现了无论服务请求端在什么阶段修改目的地,均能够为服务提供端派送匹配的下一个订单,实现了无论在什么阶段出现目的地修改,也均能够通过新的实际可能到达的目的地来派送新的下一个订单来实现提升车辆的利用效率。

在第一方面的一些可选的实现方式中,在所述以所述实际可能到达的目的地为所述服务提供端的位置,为所述服务提供端派送下一个订单之后之后,所述方法还包括:根据所述服务提供端的当前位置和所述实际可能到达的目的地规划出送达路线,以及根据所述实际可能到达的目的地和所述下一个订单中的出发地点规划出接单路线;将所述送达路线和所述接单路线均发送至所述下一个订单所对应的下一个服务请求端。

在本申请实施例中,通过该将规划出送达路线和接单路线发送给该下一个订单所对应的服务请求端,使得服务请求端能够提前的知晓服务提供端的路线,避免服务请求端因不知道服务提供端的送达路线而误以为服务提供端绕路来接自己的情况出现,提升了服务请求端的使用体验。

第二方面,本申请实施例提供了一种获得模块,用于获得服务提供端的当前服务中订单的目的地;

预估模块,用于基于所述目的地,以及基于目的地与所述目的地相同的历史订单实际到达的目的地,预估所述当前服务中订单实际可能到达的目的地。

派单模块,用于以所述实际可能到达的目的地为所述服务提供端的位置,为所述服务提供端派送下一个订单。

在第二方面的一些可选的实现方式中,所述预估模块,还用于基于所述目的地,判断所述当前服务中订单对应的服务请求端的历史订单中是否有历史订单的目的地与所述目的地相同的m个历史订单,m为正整数;若是,根据所述m个历史订单中n个实际到达的目的地,预估所述当前服务中订单实际可能到达的目的地,n为不大于m的正整数。

在第二方面的一些可选的实现方式中,所述预估模块,还用于从所述m个历史订单中获得n个实际到达的目的地;根据所述m个历史订单的数量,计算出所述n个实际到达的目的地中每个实际到达的目的地的到达概率;获得所述n个实际到达的目的地中到达概率最大的目的地,确定所述到达概率最大的目的地为预估的所述当前服务中订单实际可能到达的目的地。

在第二方面的一些可选的实现方式中,所述预估模块,还用于判断所述n个实际到达的目的地中是否有到达概率最大的目的地;若是,获得所述到达概率最大的目的地;若否,将所述n个实际到达的目的地中随机选择出的目的地作为所述到达概率最大的目的地。

在第二方面的一些可选的实现方式中,所述预估模块,还用于若没有历史订单的目的地与所述目的地相同的m个历史订单,获得其它服务请求端的其它历史订单的目的地与所述目的地相同的p个其它历史订单,p为正整数;根据所述p个其它历史订单中q个实际到达的目的地,预估所述当前服务中订单实际可能到达的目的地,q为不大于p的正整数。

在第二方面的一些可选的实现方式中,所述预估模块,还用于从所述p个其它历史订单中获得q个实际到达的目的地;根据所述p个其它历史订单的数量,计算出所述q个实际到达的目的地中每个实际到达的目的地的到达概率;获得所述q个实际到达的目的地中到达概率最大的目的地,确定所述到达概率最大的目的地作为预估的所述当前服务中订单实际可能到达的目的地。

在第二方面的一些可选的实现方式中,所述预估模块,还用于若没有历史订单的目的地与所述目的地相同的m个历史订单,根据预设的所述目的地与预设目的地关联关系,确定出所述预设目的地;确定所述预设目的地为预估的所述当前服务中订单实际可能到达的目的地。

在第二方面的一些可选的实现方式中,所述获得模块,还用于在确定服务提供端的当前服务中订单的目的地有修改时,将修改后的目的地作为所述服务提供端的目的地。

在第二方面的一些可选的实现方式中,所述装置包括:

监测模块,用于在监测所述当前服务中订单而确定所述当前服务中订单的目的地有修改时,获得所述当前服务中订单的修改后的目的地。

所述预估模块,还用于基于所述修改后的目的地,以及基于目的地与所述修改后的目的地相同的历史订单实际到达的目的地,预估所述当前服务中订单新的实际可能到达的目的地。

所述派单模块,还用于以所述新的实际可能到达的目的地为所述服务提供端的位置,为所述服务提供端派送下一个订单。

在第二方面的一些可选的实现方式中,所述装置还包括:

路线规划模块,用于根据所述服务提供端的当前位置和所述实际可能到达的目的地规划出送达路线,以及根据所述实际可能到达的目的地和所述下一个订单中的出发地点规划出接单路线。

路线发送模块,用于将所述送达路线和所述接单路线均发送至所述下一个订单所对应的下一个服务请求端。

第三方面,本申请实施例提供了一种服务器,所述服务器包括:处理器,存储器,总线和通信模块。所述处理器、所述通信模块和存储器通过所述总线连接。所述存储器,用于存储程序。所述处理器,用于通过调用存储在所述存储器中的程序以执行第一方面或第一方面的任一可选的实现方式所述的连环派单方法。

第四方面,本申请实施例提供了一种具有处理器可执行的非易失程序代码的计算机可读储存介质,所述程序代码使所述处理器执行第一方面或第一方面的任一可选的实现方式所述的连环派单方法。

为使本申请的上述目的、特征和优点能更明显易懂,下文特举较佳实施例,并配合所附附图,作详细说明如下。

附图说明

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

图1示出了本申请第一实施例提供的一种连环派单系统的结构框图;

图2示出了本申请第一实施例提供的一种连环派单系统中服务器的结构框图;

图3示出了本申请第二实施例提供的一种连环派单方法的第一流程图;

图4示出了本申请第二实施例提供的一种连环派单方法中步骤s200的子流程图;

图5示出了本申请第二实施例提供的一种连环派单方法的第二流程图;

图6示出了本申请第二实施例提供的一种连环派单方法的第三流程图;

图7示出了本申请第三实施例提供的一种连环派单装置的第结构框图。

具体实施方式

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

应注意到:相似的标号和字母在下面的附图中表示类似项,因此,一旦某一项在一个附图中被定义,则在随后的附图中不需要对其进行进一步定义和解释。术语“第一”、“第二”等仅用于区分描述,而不能理解为指示或暗示相对重要性。再者,本申请中术语“和/或”,仅仅是一种描述关联对象的关联关系,表示可以存在三种关系,例如,a和/或b,可以表示:单独存在a,同时存在a和b,单独存在b这三种情况。

第一实施例

请参阅图1,本申请的提供了一种连环派单系统10,该连环派单系统10包括:服务提供端11、服务请求端12和服务器20。

服务提供端11可以为安装并运行在服务提供者的终端上的app(application、应用程序),服务提供者可以为提供服务的用户,例如为司机。服务提供端11通过网络可以与服务器20进行数据通信,。服务请求端12也可以为安装并运行在服务请求者的终端上的app,服务请求者可以为请求服务的用户,例如为乘客。服务请求端12也通过网络也可以与服务器20进行数据通信。服务提供端11和服务请求端12通过与服务器20的数据通信,则可以实现预约网约载具的各种功能。

其中,该服务提供端11可以为服务提供者的手机、平板电脑或司机车辆内安装的车载设备等移动终端,该服务请求端12可以为服务提供者的手机、平板电脑等移动终端。

如图2所示,服务器20可以为网络服务器、数据库服务器或由多个子服务器构成的服务器集群。服务器20通过分别与司机客户端11和乘客客户端12进行数据交互,可以执行并实现涉及网约打车的连环派单方法。

可选地,服务器20可以包括:存储器21、通信模块22、总线23和处理器24。其中,处理器24、通信模块22和存储器21通过总线23连接。处理器24用于执行存储器21中存储的可执行模块,例如计算机程序。图2所示的服务器20的组件和结构只是示例性的,而非限制性的,根据需要,服务器20也可以具有其他组件和结构。

其中,存储器21可能包含高速随机存取存储器(randomaccessmemoryram),也可能还包括非不稳定的存储器(non-volatilememory),例如至少一个磁盘存储器。本实施例中,存储器21存储了处理器24执行连环派单方法所需要的程序。

总线23可以是isa总线、pci总线或eisa总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示,图2中仅用一个双向箭头表示,但并不表示仅有一根总线或一种类型的总线。

处理器24可能是一种集成电路芯片,具有信号的处理能力。在实现过程中,上述方法的各步骤可以通过处理器24中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器24可以是通用处理器,包括中央处理器(centralprocessingunit,简称cpu)、网络处理器(networkprocessor,简称np)等;还可以是数字信号处理器(dsp)、专用集成电路(asic)、现成可编程门阵列(fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本发明实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成,或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器,闪存、只读存储器,可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。

本发明实施例任意实施例揭示的流过程或定义的装置所执行的方法可以应用于处理器24中,或者由处理器24实现。处理器24在接收到执行指令后,通过总线23调用存储在存储器21中的程序后,处理器24通过总线23控制通信模块22则可以执行连环派单方法的流程。

第二实施例

本实施例提供了一种连环派单方法,需要说明的是,在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行,并且,虽然在流程图中示出了逻辑顺序,但是在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤。以下对本实施例进行详细介绍。

请参阅图3,在本实施例提供的连环派单方法中,该连环派单方法从服务器20的角度进行描述,且该连环派单方法可以包括:步骤s100、步骤s200和步骤s300。

步骤s100:获得服务提供端的当前服务中订单的目的地。

步骤s200:基于所述目的地,以及基于目的地与所述目的地相同的历史订单实际到达的目的地,预估所述当前服务中订单实际可能到达的目的地。

步骤s300:以所述实际可能到达的目的地为所述服务提供端的位置,为所述服务提供端派送下一个订单。

下面将结合图1-图3对本申请的方案中的各个步骤进行详细的描述。

步骤s100:获得服务提供端的当前服务中订单的目的地。

服务请求者在被接送的过程中,服务请求端12和服务提供端11上该服务请求者的订单的状态则处于当前服务中的状态。那么针对该当前服务中的状态的当前服务中订单,为保证服务提供端12能够正确的接到服务请求者并把服务请求者正确的送达服务请求者的目的地处,该当前服务中订单中则可以包括前服务中订单的出发地和前服务中订单的目的地,其中,该前服务中订单的出发地和前服务中订单的目的地可以为服务请求者需要预定网约载具而基于服务请求端12发送该订单时确定的出发地和目的地。

可以理解到的是,该当前服务中订单在被服务器20派送到该服务提供端11并开始服务之前,服务请求端12需要向服务器20提交该当前服务中订单。这样,服务器20就能够从服务请求端12提交的当前服务中订单中获得当前服务中订单的目的地。

可以理解到,服务器20可以根据服务请求端12提交的当前服务中订单获得该当前服务中订单的目的地,由于该当前服务中订单也是服务提供端正在服务的订单,可以理解为相当于服务器20获得了该服务提供端的当前服务中订单的目的地。此外,服务器20获得该当前服务中订单的目的地的时间点可以为服务提供端11从开始执行当前服务中订单至执行完成当前服务中订单中的任意时刻。本实施例中,以服务器20在服务提供端11接到并开始执行当前服务中订单时获得该当前服务中订单的目的地为例进行说明,但并不作为限定。

另外,作为一种可选的实施方式,服务请求者可以基于服务请求端12对该当前服务中订单中的目的地进行修改。例如,服务请求者在之前发起该当前服务中订单时将该当前服务中订单的目的地设置错了,又例如,服务请求者在去往该当前服务中订单的目的地的途中,由于个人事务的调整而不需要再去往该当前服务中订单的目的地。那么当服务请求者在服务请求端12修改该当前服务中订单的目的地后,服务器20会监测到并确定该该当前服务中订单的目的地有修改。服务器20可以将修改后的目的地作为该当前服务中订单的目的地,那么服务器20后续预估当前服务中订单实际可能到达的目的地时,以修改后的目的地作为当前服务中订单的目的地,使得后续的预估结果更为准确。

步骤s200:基于所述目的地,以及基于目的地与所述目的地相同的历史订单实际到达的目的地,预估所述当前服务中订单实际可能到达的目的地。

在本实施例中,由于当前服务中订单的目的地是服务请求者需要去往的地点,但因为实际情况的限制,往往导致服务请求者下车的实际目的地往往与该当前服务中订单的目的地不相同。例如,因为交通拥堵导致服务请求者无法到达该当前服务中订单的目的地、或因为个人因素使得服务请求者在未修改当前服务中订单的目的地基础上不再去往该当当前服务中订单的目的地、亦或是因为该当前服务中订单的目的地是个范围区域而导致服务请求者在范围区域下车的实际目的地与当前服务中订单的目的地不同(通常情况下,在当前服务中订单的目的地为范围区域时,该当前服务中订单的目的地的定位位置往往是在该范围区域中。例如当前服务中订单的目的地为x小区,那么该当前服务中订单的目的地为的定位位置一般在该x小区中,且只有通过该x小区的内部道路才能到达该定位位置。这样就会导致服务请求者下车的实际目的地与该当前服务中订单的目的地不同)。

这种情况下,若按照当前服务中订单的目的地为服务提供端11为位置,为服务提供端11继续派送下一个订单,那么服务提供端11在开始执行该下一个订单时,若服务提供端11按照出发地点去接该下一个订单的下一个服务请求者,则可能出现绕路的情况。

假设,某市有一个较大的园区,且该园区有相隔较远的a门和b门。若服务请求者的当前服务中订单中的目的地为a门,那么服务器20根据目的地为a门为服务提供者的服务提供端11派送的下一个订单的出发地点则也是a门。可是,服务请求者实际却到达了该园区的b门,并在b门下车。这样,服务提供者就必须再从b门绕回a门去接下一个订单的下一个服务请求者。这就造成了服务提供者绕路,导致载具利用率降低。且该下一个服务请求者又需要等待该服务提供者绕回来,那么下一个服务请求者的等待时间也导致该下一个服务请求者的体验不太好。

故为避免上述载具利用率降低和服务请求者的体验不太好问题出现,服务器20就需要在当前服务中订单的服务请求者下车前先预估出该当前服务中订单实际可能到达的目的地,使得该预估出的实际可能到达的目的地极有可能与服务请求者实际下车的地点相同。

可选地,服务器20可以基于当前服务中订单的目的地,以及基于目的地与该当前服务中订单的目的地的历史订单实际到达的目的地,来预估该当前服务中订单的实际可能到达的目的地。例如,服务器20基于当前服务中订单的目的地去历史数据中获得目的地为该当前服务中订单的目的地的历史订单。基于获得历史订单,服务器20就可以获知历史中的服务请求者们在目的地为该当前服务中订单的目的地的情况下,这些服务请求者实际都在哪些位置下车,并这些实际下车的位置中下车次数最多的位置作为预估的实际可能到达的目的地。这样,该实际可能到达的目的地也就是该服务请求者实际可能的下车位置中最有可能下车的位置。因此,服务器20便可以以该预估的实际可能到达的目的地作为派送下一个订单的依据。

步骤s300:以所述实际可能到达的目的地为所述服务提供端的位置,为所述服务提供端派送下一个订单。

服务器20预估出实际可能到达的目的地后,服务器20则可以以该实际可能到达的目的地为依据来寻找与该实际可能到达的目的地匹配的下一个订单。

可选地,服务器20寻找与该实际可能到达的目的地匹配的下一个订单的方式可以为,服务器20可以以该实际可能到达的目的地为服务提供端的位置,在订单池中查找是否有出发位置与该服务提供端11的位置匹配的订单。其中,出发位置与该服务提供端11的位置匹配可以为出发位置与该实服务提供端的位置之间的距离不超过预设距离。从而服务器20通过查找和匹配,则可以找到与该服务提供端11的位置匹配的订单,该匹配的订单的出发位置即可以为与该服务提供端11的位置相同或与该服务提供端11的位置的距离最短。这样,服务器20就可以把该匹配的订单作为该服务提供者的下一个订单派送给到服务提供者的服务提供端11。

可以理解到,为保证当前服务中订单的服务请求者的服务体验,服务提供端11在获得下一个订单后,服务提供端11并不会马上播报该下一个订单,而是在当前服务中订单完成时才提示服务提供者接收到该下一个订单。

请参阅图4,在本申请一些可选的实施方式中,步骤s200的流程可以包括:步骤s210和步骤s220。

步骤s210:基于所述目的地,判断所述当前服务中订单对应的服务请求端的历史订单中是否有历史订单的目的地与所述目的地相同的m个历史订单,m为正整数。

步骤s220:若是,根据所述m个历史订单中n个实际到达的目的地,预估所述当前服务中订单实际可能到达的目的地,n为不大于m的正整数。

下面将对本申请的步骤s200进行具体的描述。

步骤s210:基于所述目的地,判断所述当前服务中订单对应的服务请求端的历史订单中是否有历史订单的目的地与所述目的地相同的m个历史订单,m为正整数。

服务器20在获得当前服务中订单的目的地后,服务器20可以对该当前服务中订单对应的服务请求端12的历史出行数据进行查找,以基于该目的地判断在该服务请求端12的历史出行数据中是否查找出有目的地与该当前服务中订单的目的地相同的m个历史订单,其中,m可以为正整数。

作为一种可选地实施方式,服务器20对该当前服务中订单对应的服务请求端12的历史出行数据进行查找的方式可以为:由于该当前服务中订单的各种信息中也包括了服务请求端12的用户信息,那么服务器20在获得目的地的同时,服务器20也获得了该服务请求端12的用户信息。服务器20基于该服务请求者的用户信息,便可以在数据库中查找到与该服务请求端12的历史出行数据。其中,数据库可以为设置在该服务器20中或数据库也可以为有专门的设备提供。服务器20对该服务请求端12的历史出行数据进行遍历,便可以继续查找并判断是否在历史出行数据查找出有目的地与该当前服务中订单的目的地相同的m个历史订单。

步骤s220:若是,根据所述m个历史订单中n个实际到达的目的地,预估所述当前服务中订单实际可能到达的目的地,n为不大于m的正整数。

作为本实施例的第一种可选地实施方式,若服务器20在历史出行数据查找出有目的地与该当前服务中订单的目的地相同的m个历史订单。

例如,查找出该服务请求端a有5个历史订单,那么5个历史订单的目的地均与该当前服务中订单的目的地相同,其中,历史订单的目的地也为该服务请求端a当时发起历史订单时确定的目的地。

服务器20基于对m个历史订单中每个历史订单进行解析,那么服务器20便可以获得每个历史订单中当时该服务请求端12实际到达的目的地。

可以理解到的是,服务器20获得该服务请求端12每个实际到达的目的地时,由于历史订单为m个,实际上服务器20共获得了m个实际到达的目的地。但由于在该m个实际到达的目的地中可能存在同样的地点,即服务请求端12可能在一个地点多次下车,故服务器20便可以将该m个实际到达的目的地中同样地点的至少两个实际到达的目的地作为一个实际到达的目的地。这样,服务器20便可以m个实际到达的目的地获得n个实际到达的目的地。由于服务器20在将同样地点的至少两个实际到达的目的地作为一个实际到达的目的地的过程中,服务器20可以对每个地点有几个实际到达的目的地进行统计,故服务器20便可获得n个实际到达的目的地中每个实际到达的目的地的到达次数。并基于m个历史订单的数量为m个,计算出该n个实际到达的目的地中每个实际到达的目的地的到达概率。

继续以前述例子为例,在查找出的5个历史订单中,其中三个实际到达的目的地为该服务请求端a在该园区的b门处下车,另外一个实际到达的目的地为该服务请求端a在该园区的a门处下车,而最后一个实际到达的目的地为该服务请求端a在该园区的c门处下车。那么服务器20便从5个历史订单获得该3个实际到达的目的地,分别是园区的b门、园区的a门和园区的c门。这样服务器20就可以计算出该实际到达的3个历史目的地中,到达园区的b门的实际到达的目的地的到达概率为3/5,到达园区的a门的实际到达的目的地的到达概率为1/5,以及到达园区的c门的实际到达的目的地的到达概率为1/5。

服务器20获得每个实际到达的目的地的到达概率后,服务器20则基于每个实际到达的目的地的到达概率来确定出到达概率最大的目的地。可选地,服务器20可以判断该n个实际到达的目的地中是否有到达概率最大的目的地。

在判断为是时,服务器20获得该到达概率最大的目的地,并确定该到达概率最大的目的地为预估的该当前服务中订单实际可能到达的目的地。

继续以前述例子为例,在到达园区的b门的实际到达的目的地的到达概率为3/5,到达园区的a门的实际到达的目的地的到达概率为1/5,以及到达园区的c门的实际到达的目的地的到达概率为1/5的情况下,服务器20基于判断可以确定出到达园区的b门的实际到达的目的地为到达概率最大的目的地,并将该到达园区的b门的实际到达的目的地作为当前服务中订单实际可能到达的目的地。

在判断为否时,则说明实际到达的n个实际到达的目的地中每个实际到达的目的地的到达概率都是相同的。

这种情况下,作为一种方式,服务器20可以将该n个实际到达的目的地中随机选择出的实际到达的目的地作为该到达概率最大的目的地,并也确定该到达概率最大的目的地为预估的该当前服务中订单实际可能到达的目的地。

这种情况下,作为另一种方式,服务器20则还可以在数据库中查找其它服务请求端12的历史订单的目的地与该当前服务中订单的目的地相同的多个历史订单,那么服务器20可以将多个历史订单中到达概率最大的实际到达的目的地作为该当前服务中订单最有可能到达的实际可能到达的目的地。

可以理解到,上述两种方式仅为本实施例的一些可选地方式,并不作为对本实施例的限定,甚至本实施例还可以采用将其它服务请求者的多个历史订单与该服务请求者的m个历史订单结合来进行达概率最大的历史目的地的选择,但也不作为对本实施例的限定。

又例如,查找出该服务请求端a有6个历史订单,且根据这6个历史订单获得在到达园区的b门的实际到达的目的地的到达概率为1/3,到达园区的a门的实际到达的目的地的到达概率为1/3,以及到达园区的c门的实际到达的目的地的到达概率为1/3的情况下。服务器20可以随机选择出到达园区的b门的实际到达的目的地为到达概率最大的目的地,并将该到达园区的b门的实际到达的目的地作为当前服务中订单实际可能到达的目的地。或者服务器20可以参考其它服务请求端的多个历史订单,从而确定到达园区的a门的实际到达的目的地为到达概率最大的目的地,并将该到达园区的a门的实际到达的目的地作为当前服务中订单实际可能到达的目的地。

作为本实施例的第二种可选地实施方式,若服务器20基于步骤s210的判断,而未在历史出行数据查找出有目的地与该当前服务中订单的目的地相同的m个历史订单,故可以说明该服务请求端12是首次去往该目的地。这种情况下,服务器20便无法再以该服务请求端12的历史出行数据作为依据,当然,本打车平台可以获取其他网约载具平台的历史数据的情况除外。

服务器20可以基于该当前服务中订单的目的地对数据库进行查找,而获得数据库中其他服务请求端12的其它历史订单的目的地与该当前服务中订单的目的地相同的p个其它历史订单,其中,p可以为正整数。

作为一种可选地实施方式,服务器20获得对该p个其它历史订单的方式可以为:服务器20基于该当前服务中订单的目的地在数据库中的其它服务请求者的历史出行数据中进行遍历,从而在数据库中查找出其它历史订单的目的地与该当前服务中订单的目的地相同的p个历史订单。可以理解到,该p个历史订单的数量需要足够多,使得后续基于p个历史订单能够确定出到达概率最大的实际到达的目的地。那么,该p个历史订单可以为一个其它服务请求端12的历史订单,或者,在一个其它服务请求端12的历史订单的数量不够多的情况下,该p个历史订单也可以为多个其它服务请求端12的历史订单。

又例如,服务器20未查找到该服务请求端a有历史订单,那么服务器20可以查找出该其它服务请求端b的其它历史订单的目的地与该当前服务中订单的目的地相同的10个其它历史订单,其中,该其它历史订单的目的地也为该其它服务请求者端b当时发起该其它历史订单时确定的目的地。

服务器20基于对p个其它历史订单中每个其它历史订单进行解析,那么服务器20便可以获得每个其它历史订单中当时该其它服务请求者实际到达的目的地,共p个实际到达的目的地。类似的是,服务器20也基于将该p个实际到达的目的地中同样地点的至少两个实际到达的目的地作为一个实际到达的目的地,那么服务器20也可以从该p个其它历史订单中获得q个实际到达的目的地。以及服务器20也可以基于对每个地点有几个实际到达的目的地进行统计,故服务器20便可获得q个实际到达的目的地中每个实际到达的目的地的到达次数。并也基于p个其它历史订单的数量,计算出该q个实际到达的目的地中每个实际到达的目的地的到达概率。

继续以前述例子为例,在查找出的10个其它历史订单中,其中三个实际到达的目的地为该其它服务请求端b在该园区的b门处下车,另外六个实际到达的目的地为该其它服务请求端b在该园区的a门处下车,而最后一个实际到达的目的地为该其它服务请求端b在该园区的c门处下车。那么服务器20便从10个其它历史订单获得该实际到达的3个实际到达的目的地,分别是园区的b门、园区的a门和园区的c门。这样服务器20就可以计算出该3个实际到达的目的地中,到达园区的b门的实际到达的目的地的到达概率为3/10,到达园区的a门的实际到达的目的地的到达概率为3/5,以及到达园区的c门的实际到达的目的地的到达概率为1/10。

相应的,服务器20获得每个实际到达的目的地的到达概率后,服务器20可以基于实际到达的目的地的到达概率,从该q个实际到达的目的地中确定出到达概率最大的实际到达的目的地,从而可以将该到达概率最大的目的地作为预估的该当前服务中的订单实际可能到达的目的地。

也例如,在到达园区的b门的实际到达的目的地的到达概率为3/10,到达园区的a门的实际到达的目的地的到达概率为3/5,以及到达园区的c门的实际到达的目的地的到达概率为1/10的情况下,服务器20可以确定出到达园区的a门的实际到达的目的地为到达概率最大的实际到达的目的地,并将该到达园区的b门的实际到达的目的地作为当前服务中订单实际可能到达的目的地。

作为本实施例的第三种可选地实施方式,若服务器20也基于步骤s210的判断,而未在历史出行数据查找出有目的地与该当前服务中订单的目的地相同的m个历史订单,故可以说明该服务请求端12是首次去往该目的地。这种情况下,服务器20也便不能在以该服务请求端12的历史出行数据作为依据。那么,服务器20可以采用预先建立该当前服务中订单的目的地与预设目的地之间的关联关系的方式,其中,该预设目的地为服务器20基于历史数据的统计而确定出最有可能达到的目的地。故服务器20可以根据该当前服务中订单的目的地查找到该预先建立的关联关系,并根据该关联关系获得该当前服务中订单的目的地关联的预设目的地。即服务器20便可以将该预设目的地作为预估的该当前服务中订单实际可能到达的目的地。

请参阅图5,在本申请一些可选的实施方式中,步骤s300之后,该连环派单方法的步骤还可以包括:步骤s400、步骤s500和步骤s600。

步骤s400:在监测所述当前服务中订单而确定所述当前服务中订单的目的地有修改时,获得所述当前服务中订单的修改后的目的地。

步骤s500:基于所述修改后的目的地,以及基于目的地与所述修改后的目的地相同的历史订单实际到达的目的地,预估所述当前服务中订单新的实际可能到达的目的地。

步骤s600:以所述新的实际可能到达的目的地为所述服务提供端的位置,为所述服务提供端派送下一个订单。

下面将对本申请的上述步骤进行详细的描述。

服务器20预估出实际可能到达的目的地,并基于实际可能到达的目的地为服务提供端11的位置,为服务提供端11派送与与该服务提供端11的位置匹配的下一个订单的过程中。若当前服务中订单并未结束,那么当前服务中订单中还存在着当前服务中订单的目的地被修改的可能性,所以服务器20可以继续对服务提供端11上的当前服务中订单进行实时的监测。

通过监测,若服务器20确定该当前服务中订单中的目的地有修改时,服务器20则获得该当前服务中订单中修改后的目的地。这种情况下,为保证预估的实际可能到达的目的地的准确性,那么服务器20就需要基于该修改后的目的地,以及基于目的地与目的地为该修改后的目的地相同的历史订单实际到达的目的地,重新预估出该当前服务中订单的新的实际可能到达的目的地。

可以理解到,重新预估的具体流程可参阅上述对预估具体流程的具体描述,为保证描述的简洁性,在此就不再累述。

为降低服务器20的运算负荷,服务器20基于重新预估出的该新的实际可能到达的目的地,服务器20可以先判断该新的实际可能到达的目的地是否与基于修改前的目的地预估出的实际可能到达的目的地相同。

若相同,那么服务器20可以不为服务提供端11派送新的下一个订单,使得服务提供端11后续服务的订单还是为该基于修改前的目的地而获得的下一个订单。这样就省略了服务器20再次寻找和匹配订单的过程,降低了服务器20的运算负荷。

若不相同,那么服务器20可以基于该新的实际可能到达的目的地为服务提供端11位置,而查找到与该服务提供端11位置匹配的新的下一个订单,并为该服务提供端11派送该新的下一个订单。

可以理解到,重新查找与该新的实际可能到达的目的地匹配的新的下一个订单具体流程可参阅上述对查找与实际可能到达的目的地匹配的下一个订单具体流程的具体描述,为保证描述的简洁性,在此就不再累述。

请参阅图6,在本申请一些可选的实施方式中,步骤s300之后,该连环派单方法的流程还可以包括:步骤s700和步骤s800。

步骤s700:根据所述服务提供端的当前位置和所述实际可能到达的目的地规划出送达路线,以及根据所述实际可能到达的目的地和所述下一个订单中的出发地点规划出接单路线。

步骤s800:将所述送达路线和所述接单路线均发送至所述下一个订单所对应的下一个服务请求端。

下面将对本申请的上述步骤进行详细的描述。

步骤s700:根据所述服务提供端的当前位置和所述实际可能到达的目的地规划出送达路线,以及根据所述实际可能到达的目的地和所述下一个订单中的出发地点规划出接单路线。

本实施例中,服务器20不仅可以对服务请求端12的状态进行持续的检测,服务器20还可以对服务提供端11的状态进行持续的检测。这样,服务器20就能够获得服务提供端11的实时状态、实时位置等,其中,实时状态用于表示该服务提供端11处于空闲或服务中状态。

在获得下一个订单后,服务器20基于服务提供端11的实时位置和该当前服务中订单的实际可能到达的目的地,以及基于该服务提供端11所在地区的地图数据,服务器20可以规划出将该当前服务中订单的服务请求端12送达至实际可能到达的目的地的送达路线。服务器20还可以基于实际可能到达的目的地和以该服务提供端11的位置为该服务提供端11派送下一个订单中的出发地点,以及基于该服务提供端11所在地区的地图数据,服务器20可以规划出从实际可能到达的目的地去出发地点接下一个服务请求端12的接单路线。

步骤s800:将所述送达路线和所述接单路线均发送至所述下一个订单所对应的下一个服务请求端。

服务器20可以将该送达路线和接单路线均发送至所述下一个订单所对应的下一个服务请求者的服务请求端12,且服务器20还将该服务提供端11的当前状态也发送到下一个服务请求者的服务请求端12。这样,下一个服务请求端12将送达路线和接单路线在界面上显示出来,并也将该服务提供端11的当前状态显示出来,下一个服务请求就可以知晓为自己服务的服务提供者当前还处于服务中状态,且也能够获得服务提供者的服务路线。那么就算送达路线和接单路线存在绕路的情况,但下一个服务请求者也能够清楚的知道当前的实际情况并不是服务提供者故意绕路,故提升了下一个服务请求者的使用体验。

以及,在该当前服务中订单完成时,服务器20还要把服务提供者的联系方式发送给下一个服务请求者的服务请求端12,以避免下一个服务请求者提前联系服务提供者而影响到当前服务中订单的服务请求者的服务体验。

第三实施例

请参阅图7,本申请实施例提供了一种连环派单装置100,该连环派单装置100应用于服务器20,该连环派单装置100包括:

获得模块110,用于获得服务提供端的当前服务中订单的目的地。

预估模块120,用于基于所述目的地,以及基于目的地与所述目的地相同的历史订单实际到达的目的地,预估所述当前服务中订单实际可能到达的目的地。

派单模块130,用于以所述实际可能到达的目的地为所述服务提供端的位置,为所述服务提供端派送下一个订单。

其中,所述预估模块120,还用于基于所述目的地,判断所述当前服务中订单对应的服务请求端的历史订单中是否有历史订单的目的地与所述目的地相同的m个历史订单,m为正整数;若是,根据所述m个历史订单中n个实际到达的目的地,预估所述当前服务中订单实际可能到达的目的地,n为不大于m的正整数。

所述预估模块120,还用于从所述m个历史订单中获得n个实际到达的目的地;根据所述m个历史订单的数量,计算出所述n个实际到达的目的地中每个实际到达的目的地的到达概率;获得所述n个实际到达的目的地中到达概率最大的目的地,确定所述到达概率最大的目的地为预估的所述当前服务中订单实际可能到达的目的地。

所述预估模块120,还用于判断所述n个实际到达的目的地中是否有到达概率最大的目的地;若是,获得所述到达概率最大的目的地;若否,将所述n个实际到达的目的地中随机选择出的目的地作为所述到达概率最大的目的地。

所述预估模块120,还用于若没有历史订单的目的地与所述目的地相同的m个历史订单,获得其它服务请求端的其它历史订单的目的地与所述目的地相同的p个其它历史订单,p为正整数;根据所述p个其它历史订单中q个实际到达的目的地,预估所述当前服务中订单实际可能到达的目的地,q为不大于p的正整数。

所述预估模块120,还用于从所述p个其它历史订单中获得q个实际到达的目的地;根据所述p个其它历史订单的数量,计算出所述q个实际到达的目的地中每个实际到达的目的地的到达概率;获得所述q个实际到达的目的地中到达概率最大的目的地,确定所述到达概率最大的目的地作为预估的所述当前服务中订单实际可能到达的目的地。

所述预估模块120,还用于若没有历史订单的目的地与所述目的地相同的m个历史订单,根据预设的所述目的地与预设目的地关联关系,确定出所述预设目的地;确定所述预设目的地为预估的所述当前服务中订单实际可能到达的目的地。

以及,所述获得模块110,还用于在确定服务提供端的当前服务中订单的目的地有修改时,将修改后的目的地作为所述服务提供端的目的地。

请参阅图7,本申请实施例中,该连环派单装置100还包括:

监测模块140,还用于在监测所述当前服务中订单而确定所述当前服务中订单的目的地有修改时,获得所述当前服务中订单的修改后的目的地。

所述预估模块120,还用于基于所述修改后的目的地,以及基于目的地与所述修改后的目的地相同的历史订单实际到达的目的地,预估所述当前服务中订单新的实际可能到达的目的地。

所述派单模块130,还用于以所述新的实际可能到达的目的地为所述服务提供端的位置,为所述服务提供端派送下一个订单。

请参阅图7,本申请实施例中,该连环派单装置100还包括:

路线规划模块150,用于根据所述服务提供端的当前位置和所述实际可能到达的目的地规划出送达路线,以及根据所述实际可能到达的目的地和所述下一个订单中的出发地点规划出接单路线。

路线发送模块160,用于将所述送达路线和所述接单路线均发送至所述下一个订单所对应的下一个服务请求端。

需要说明的是,由于所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统、装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。

第四实施例

本申请实施例还提供了一种处理器可执行的非易失的程序代码的计算机可读储存介质,该计算机可读存储介质上存储有程序代码,该程序代码被处理器运行时执行上述任一实施例连环派单方法的步骤。

具体地,该存储介质能够为通用的存储介质,如移动磁盘、硬盘等,该存储介质上的程序代码被运行时,能够执行上述施例连环派单方法,从而解决载具的利用率降低,且服务请求者的使用体验变差的技术问题。

本申请实施例所提供的连环派单方法的程序代码产品,包括存储了程序代码的计算机可读存储介质,程序代码包括的指令可用于执行前面方法实施例中的方法,具体实现可参见方法实施例,在此不再赘述。

所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统和装置的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。

综上所述,本申请实施例提供了一种连环派单方法、装置、服务器及存储介质。方法包括:获得服务提供端的当前服务中订单的目的地;基于该目的地,以及基于目的地与该目的地相同的历史订单实际到达的目的地,预估当前服务中订单实际可能到达的目的地;以实际可能到达的目的地为服务提供端的位置,为服务提供端派送下一个订单。

通过服务提供端在进行当前服务中订单时,可以根据该当前服务中订单的目的地和目的地与该目的地相同的历史订单实际到达的目的地,对该当前服务中订单的实际可能到达目的地进行预估,由于预估出的实际可能到达的目的地为该当前服务中订单的服务请求端最可能到达的位置,那么以实际可能到达的目的地为服务提供端的位置为服务提供端派送下一个订单,使得服务提供端接到下一个服务请求端的路程很近,避免了服务请求端的达到点和下一个订单的起点的接驾距离太远而导致服务提供端接到下一个服务请求端的接驾成本增加的问题,提升了平台的派单效率。且由于服务提供端接到下一个服务请求端的路程很近,还缩短了下一个服务请求端的等待时间,提升了服务请求端的使用体验。

以上仅为本申请的优选实施例而已,并不用于限制本申请,对于本领域的技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本申请的保护范围之内。应注意到:相似的标号和字母在下面的附图中表示类似项,因此,一旦某一项在一个附图中被定义,则在随后的附图中不需要对其进行进一步定义和解释。

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

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1