订单分配方法及装置与流程

本申请实施例涉及互联网技术领域，特别涉及一种订单分配方法及装置。

背景技术

随着互联网技术的发展，基于互联网技术的o2o(onlinetooffline，在线离线/线上到线下)服务(例如网络约车、外卖配送等)为人们的生活带来了越来越多的便利。目前，当遇到上下班高峰期或雨雪天气时，o2o服务的需求量通常会激增，此时，如果继续按照平时的订单分配策略派发订单，则很有可能无法将服务资源集中到服务需求量更大的区域，从而造成服务资源的浪费。

技术实现要素：

为了解决上述问题，本申请实施例提供一种订单分配方法及装置。

具体地，本申请实施例是通过如下技术方案实现的：

根据本申请实施例的第一方面，提供一种订单分配方法，所述方法包括：

本申请实施例中，当检测到目标服务区域的运力不足时，向处于所述目标服务区域的备选服务区域中的待接单用户发送调度消息，其中，所述调度消息用于请求所述待接单用户回答是否同意前往所述目标服务区域接单；

当从所述待接单用户接收到同意前往所述目标服务区域接单的回答时，向所述待接单用户推送所述目标服务区域中的订单。

本申请实施例中，如下确定所述目标服务区域的备选服务区域：

获得所述目标服务区域周边服务区域的运力情况；

将所述周边服务区域中运力富余的服务区域确定为备选服务区域。

本申请实施例中，所述向所述待接单用户推送所述目标服务区域中的订单，包括：

根据设定的服务时长、以及待接单用户接受调度的时间点和待接单用户到达所述目标服务区域的时间点中的任一时间点，确定所述待接单用户的服务时段；

在所述服务时段内向所述待接单用户推送所述目标服务区域中的订单。

本申请实施例中，所述方法还包括：

获得同意前往所述目标服务区域接单的待接单用户的数量；

当所述数量大于设定的数量阈值时，停止向所述备选服务区域中的待接单用户发送调度消息。

本申请实施例中，所述方法还包括：

在从所述待接单用户接收到同意前往所述目标服务区域接单的回答的情况下，判断所述待接单用户是否在规定时长内达到所述目标服务区域；

当所述待接单用户在规定时长内达到所述目标服务区域时，向所述待接单用户发放奖励。

本申请实施例中，所述方法还包括：

当检测到发生预设类型的事件时，检测目标服务区域的运力是否不足。

本申请实施例中，所述预设类型的事件包括下述至少一种：

预设类型的天气、上下班高峰期、重大节日或会议事件。

根据本申请实施例的第二方面，提供一种订单分配装置，所述装置包括：

消息发送模块，用于在检测到目标服务区域的运力不足的情况下，向处于所述目标服务区域的备选服务区域中的待接单用户发送调度消息，其中，所述调度消息用于请求所述待接单用户回答是否同意前往所述目标服务区域接单；

订单推送模块，用于在从所述待接单用户接收到同意前往所述目标服务区域接单的回答时，向所述待接单用户推送所述目标服务区域中的订单。

本申请实施例中，所述装置还包括：备选区域确定模块，其中，所述备选区域确定模块，包括：

运力情况获得子模块，用于在检测到目标服务区域的运力不足的情况下，获得所述目标服务区域周边服务区域的运力情况；

备选服务区域确定子模块，用于将所述周边服务区域中运力富余的服务区域确定为备选服务区域。

本申请实施例中，所述订单推送模块，包括：

服务时段确定子模块，用于根据设定的服务时长、以及待接单用户接受调度的时间点和待接单用户到达所述目标服务区域的时间点中的任一时间点，确定所述待接单用户的服务时段；

订单推送子模块，用于在所述服务时段内向所述待接单用户推送所述目标服务区域中的订单。

本申请实施例中，所述装置还包括：

用户数量获得模块，用于获得同意前往所述目标服务区域接单的待接单用户的数量；

控制模块，用于在所述用户数量获得模块获得的数量大于设定的数量阈值的情况下，停止向所述备选服务区域中的待接单用户发送调度消息。

本申请实施例中，所述装置还包括：

判断模块，用于在从所述待接单用户接收到同意前往所述目标服务区域接单的回答的情况下，判断所述待接单用户是否在规定时长内达到所述目标服务区域；

奖励发放模块，用于在所述判断模块的判断结果为是的情况下，向所述待接单用户发放奖励。

本申请实施例中，所述装置还包括：

检测模块，用于在检测到发生预设类型的事件的情况下，检测目标服务区域的运力是否不足。

本申请实施例中，所述预设类型的事件包括下述至少一种：

预设类型的天气、上下班高峰期、重大节日或会议事件。

根据本申请实施例的第三方面，提供一种计算机存储介质，所述存储介质中存储有程序指令，所述程序指令包括：

当检测到目标服务区域的运力不足时，向处于所述目标服务区域的备选服务区域中的待接单用户发送调度消息，其中，所述调度消息用于请求所述待接单用户回答是否同意前往所述目标服务区域接单；

当从所述待接单用户接收到同意前往所述目标服务区域接单的回答时，向所述待接单用户推送所述目标服务区域中的订单。

本申请实施例中，当目标服务区域的运力不足时，可以调度其他服务区域中的待接单用户前往该目标服务区域，并只向待接单用户派发该目标服务区域中的订单，从而实现了将服务资源集中到服务需求量更大的服务区域，因此，减少了服务资源的浪费。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本申请实施例。

附图说明

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

图1是根据本申请一示例性实施例示出的一种订单分配方法的流程图；

图2是根据本申请一示例性实施例示出的另一种订单分配方法的流程图；

图3是根据本申请一示例性实施例示出的一种订单分配装置的框图；

图4是根据本申请一示例性实施例示出的另一种订单分配装置的框图；

图5是根据本申请一示例性实施例示出的另一种订单分配装置的框图；

图6是根据本申请一示例性实施例示出的另一种订单分配装置的框图；

图7是根据本申请一示例性实施例示出的另一种订单分配装置的框图；

图8是根据本申请一示例性实施例示出的另一种订单分配装置的框图；

图9是根据本申请一示例性实施例示出的一种用于订单分配装置的一结构示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请实施例相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请实施例的一些方面相一致的装置和方法的例子。

在本申请实施例使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请实施例。在本申请实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

随着互联网技术的发展，基于互联网技术的o2o(onlinetooffline，在线离线/线上到线下)服务(例如网络约车、外卖配送等)为人们的生活带来了越来越多的便利。目前，当遇到上下班高峰期或雨雪天气时，o2o服务的需求量通常会激增，此时，如果继续按照平时的订单分配策略派发订单，则很有可能无法将服务资源集中到服务需求量更大的区域，从而造成服务资源的浪费。为了解决上述问题，本申请实施例提供了一种订单分配方法及装置。

下面首先对本申请实施例提供的一种订单分配方法进行介绍。

图1是根据本申请一示例性实施例示出的一种订单分配方法的流程图，如图1所示，该方法可以包括以下步骤：

在步骤101中，当检测到目标服务区域的运力不足时，向处于该目标服务区域的备选服务区域中的待接单用户发送调度消息，其中，该调度消息用于请求待接单用户回答是否同意前往目标服务区域接单。

一般，对于一个比较大的地区来说，为了提高o2o服务的服务效率，通常按照一定的区域划分规则，将一个地区划分为多个服务区域，例如按照写字楼的分布，将一个地区划分为多个服务区域，其中，服务区域指的是待接单用户提供服务的区域。

本申请实施例中，待接单用户指的是等待接单的用户，即提供o2o服务的用户，在网络约车场景下，待接单用户为司机，在外卖配送场景下，待接单用户为配送员，当然，在其他o2o服务场景下，待接单用户可以为其他身份的用户，本申请实施例对此不作限定。

本申请实施例中，运力指的是一个服务区域中的订单数量与该服务区域中的待接单用户数量的供需关系，其中，如果一个服务区域中的待接单用户的数量与订单数量相近时，则认为该服务区域的运力平衡；如果一个服务区域中的待接单用户的数量远大于订单数量时，则认为该服务区域的运力富余；如果一个服务区域中的待接单用户的数量远小于订单数量时，则认为该服务区域的运力不足。

本申请实施例中，可以通过统计目标服务区域中的订单数量与该服务区域中的待接单用户数量，来达到检测该目标服务区域的运力情况的目的。

本申请实施例中，可以实时检测目标服务区域的运动情况，也可以预先设置一定的触发条件，只有当满足预设的触发条件时，才开启检测目标服务区域的运动情况，具体的，当检测到发生预设类型的事件时，检测目标服务区域的运力是否不足，其中，该预设类型的事件可以包括下述至少一种：预设类型的天气、上下班高峰期、重大节日或会议事件。

本申请实施例中，预设的天气类型可以包括：雨、雪、大风、雾霾或冰雹等一些可能会影响交通的恶劣天气，重大节日可以包括：国庆节、五一等人们集中出行的节日。可以理解，预设的突发事件还可以是其它的事件，例如明星的演唱会等，本申请对此不作限定。

通常情况下，预设类型的事件发生后，会对一些服务区域的交通造成一定的影响。例如，当预设类型的事件为上下班高峰期时，写字楼分布较多的服务区域的交通状态会比较拥堵。

本申请实施例中，可以从气象局的网站或网络上获取当前的天气信息，根据当前的天气信息判断当前的天气是否为预设类型的天气，如果当前的天气为预设类型的天气，则确定发生了预设类型的事件。此外，可以获得当前的时间信息，根据当前的时间信息判断当前是否为上下班高峰期、或者重大节日等等。

本申请实施例中，目标服务区域的备选服务区域可以包括：目标服务区域周边的任一服务区域、目标服务区域周边的任一运力富余的服务区域、或者人为规定的服务区域，本申请实施例对此不作限定。

本申请实施例中，在网络约车场景下，处于备选服务区域中的待接单用户指的是当前所处位置位于备选服务区域内的司机，在外卖配送场景下，备选服务区域中的待接单用户指的是配送范围处于备选服务区域内的配送员。

本申请实施例中，可以通过向待接单用户的终端设备中安装的第三方o2o服务软件发送调度消息，来实现向该待接单用户发送调度消息。在网络约车场景下，终端设备中安装的第三方o2o服务软件可以为地图软件或网约车司机端软件。在外卖配送场景下，终端设备中安装的第三方o2o服务软件可以为外卖软件。

本申请实施例中，当向待接单用户的终端设备中安装的第三方o2o服务软件发送调度消息后，该第三方o2o服务软件可以在该服务软件的当前用户界面上以弹窗或卡片的形式展示调度消息的内容，并提供用户输入反馈信息的接口。

本申请实施例中，通过向处于备选服务区域中的待接单用户发送调度消息的方式，来询问该待接单用户是否同意接受o2o服务系统的调度。

在步骤102中，当从待接单用户接收到同意前往目标服务区域接单的回答时，向该待接单用户推送目标服务区域中的订单。

本申请实施例中，待接单的用户做出的回答可以包括：接受o2o服务系统的调度，即同意前往目标服务区域接单；或者拒绝o2o服务系统的调度，即拒绝前往目标服务区域接单。

本申请实施例中，当确定备选服务区域中的待接单用户接受o2o服务系统的调度时，只向该待接单用户派发目标服务区中的订单。

一般，o2o服务对应的订单中通常包括起点和终点，例如，在网络约车场景下，订单为出行订单，该出行订单中包含乘客指定的上车点(即起点)和指定的下车点(即终点)；又例如，在外卖配送场景下，订单为外卖订单，该外卖订单中包含商家的地址(即起点)和点餐的顾客的地址(即终点)。提供服务的用户在提供服务的整个过程中，其活动轨迹至少需要覆盖该起点或终点，本申请实施例中，向待接单用户推送的订单的起点、和/或终点应该处于目标服务区域中。

具体的，可以先获得o2o服务系统中待分配的订单，获得各待分配的订单的起点和终点，之后查找出起点、和/或终点处于目标服务区域中的订单，最后，将查找到的订单推送给接受系统调度的待接单用户。

以网络约车场景为例，下班高峰期，西二旗服务区域的出行订单的数量很大，但是可用网约车的数量很少，而上地服务区域的可用网约车数量很多，此时，网约车服务系统向处于上地服务区域中的司机发送调度消息，在该司机接受调度后，网约车服务系统只向该司机推送起点或终点处于西二旗服务区域的出行订单。

由上述实施例可见，该实施例中，当目标服务区域的运力不足时，可以调度其他服务区域中的待接单用户前往该目标服务区域，并只向待接单用户派发该目标服务区域中的订单，从而实现了将服务资源集中到服务需求量更大的服务区域，因此，减少了服务资源的浪费。

为了保证备选服务区域中的运力能够满足该备选服务区域中的服务需求量，在本申请的一个实施例中，目标服务区域的备选服务区域指的是运力富余的服务区域。

本申请实施例中，可以从目标服务区域周边的服务区域中筛选备选服务区域，也可以从大数据处理的角度分析出历史时间内运力始终富余的服务区域，将该运力始终富余的服务区域作为备选服务区域，本申请实施例对此不作限定。

为了确保o2o服务的服务效率，例如，应答速度，本申请实施例中，可以优先考虑从目标服务区域周边服务区域中选择备选服务区域，图2是根据本申请一示例性实施例示出的另一种订单分配方法的流程图，如图2所示，该方法可以包括以下步骤：

在步骤201中，当检测到目标服务区域的运力不足时，获得该目标服务区域周边服务区域的运力情况，将该周边服务区域中运力富余的服务区域确定为该目标服务区域的备选服务区域。

一般，相较于非周边服务区域，目标服务区域周边服务区域中的待接单用户在接受调度后，可以更快地到达目标服务区域。

本申请实施例中，可以将目标服务区域周边服务区域中运力富余的一个或多个服务区域确定为备选服务区域，本申请实施例对此不作限定。

在步骤202中，向处于目标服务区域的备选服务区域中的待接单用户发送调度消息，其中，该调度消息用于请求待接单用户回答是否同意前往目标服务区域接单。

本申请实施例中的步骤202，与图1所示实施例中的步骤101类似，本申请实施例对此不再赘述，详情请见图1所示实施例中的内容。

在步骤203中，根据设定的服务时长、以及待接单用户接受调度的时间点和待接单用户到达目标服务区域的时间点中的任一时间点，确定待接单用户的服务时段。

一般，服务区域的运力不足情况在一段时间后会有所缓解或运力恢复平衡状态，此时，可以不必再从备选服务区域调度运力，因此，本申请实施例中，可以确定一定的服务时段，在该服务时段内向待接单用户推送目标服务区域中的订单，而当超出该服务时段时，采用平时的派单策略向待接单用户推送订单。

本申请实施例中，可以根据设定的服务时长和待接单用户接受调度的时间点，计算该待接单用户的服务时段，例如，设定的服务时长为δt，待接单用户接受调度的时间点t0，那么，待接单用户的服务时段为(t0,t0+δt)。

或者，本申请实施例中，可以根据设定的服务时长和待接单用户到达目标服务区域的时间点，计算该待接单用户的服务时段，例如，设定的服务时长为δt，待接单用户到达目标服务区域的时间点t1，那么，待接单用户的服务时段为(t1,t1+δt)。

在步骤204中，在服务时段内向待接单用户推送目标服务区域中的订单。

本申请实施例中，当根据设定的服务时长和待接单用户接受调度的时间点确定服务时段时，在服务时段内，当待接单用户到达目标服务区域之前，只向该待接单用户推送终点处于目标服务区域中的订单，当待接单用户到达目标服务区域之后，只向该待接单用户推送至少起点处于目标服务区域中的订单。

或者，本申请实施例中，当根据设定的服务时长和待接单用户到达目标服务区域的时间点确定服务时段时，在服务时段内，只向该待接单用户推送至少起点处于目标服务区域中的订单；此外，当待接单用户到达目标服务区域之前，可以不向该待接单用户推送任何订单，或者只向该待接单用户推送终点处于目标服务区域中的订单。

由上述实施例可见，该实施例中，可以从目标服务区域周边服务区域中选择备选服务区域，由于相较于非周边服务区域，目标服务区域周边服务区域中的待接单用户在接受调度后，可以更快地到达目标服务区域，因此可以提高o2o服务的服务效率。此外，该实施例还可以只在服务时段内才向待接单用户推送目标服务区域中的订单，在服务时段之外不向待接单用户推送目标服务区域中的订单，因此，可以避免将服务资源长时间内集中在一个服务区域中，从而避免服务资源的浪费。

为了避免o2o服务系统大量地将其他服务区域中的运力调度到目标服务区域，造成目标服务区域中的运力过剩，导致服务资源的浪费，本申请实施例提供的另一种实施例中，该实施例可以在图1或图2所示实施例的基础上，增加以下步骤s10和s11，其中：

在s10中，获得同意前往目标服务区域接单的待接单用户的数量；

在s11中，当该数量大于设定的数量阈值时，停止向备选服务区域中的待接单用户发送调度消息。

本申请实施例中，在设置设定的数量阈值的取值时，以可以保证目标服务区域中的运力平衡为标准对该数量阈值的取值进行设置。

由上述实施例可见，该实施例中，可以通过控制调度到目标服务区域内待接单用户的数量，来避免o2o服务系统大量地将其他服务区域中的运力调度到目标服务区域，造成目标服务区域中的运力过剩，导致服务资源的浪费的情况的发生。

本申请实施例提供的另一种实施例中，如果接受调度的待接单用户在规定时间内到达目标服务区域，则向该待接单用户发放一定的奖励，此时，该实施例可以在图1或图2所示实施例的基础上，增加以下步骤s20和s21，其中：

在s20中，在从待接单用户接收到同意前往目标服务区域接单的回答的情况下，判断该待接单用户是否在规定时长内达到目标服务区域；

在s21中，当该待接单用户在规定时长内达到目标服务区域时，向该待接单用户发放奖励。

应当注意，尽管在附图中以特定顺序描述了本申请实施例方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。相反，流程图中描绘的步骤可以改变执行顺序。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

与前述订单分配方法的实施例对应，本申请实施例还提供了订单分配装置的实施例。

图3是根据本申请一示例性实施例示出的一种订单分配装置的框图，如图3所示，所述装置可以包括：

消息发送模块310，用于在检测到目标服务区域的运力不足的情况下，向处于所述目标服务区域的备选服务区域中的待接单用户发送调度消息，其中，所述调度消息用于请求所述待接单用户回答是否同意前往所述目标服务区域接单；

一般，对于一个比较大的地区来说，为了提高o2o服务的服务效率，通常按照一定的区域划分规则，将一个地区划分为多个服务区域，例如按照写字楼的分布，将一个地区划分为多个服务区域，其中，服务区域指的是待接单用户提供服务的区域。

本申请实施例中，待接单用户指的是等待接单的用户，即提供o2o服务的用户，在网络约车场景下，待接单用户为司机，在外卖配送场景下，待接单用户为配送员，当然，在其他o2o服务场景下，待接单用户可以为其他身份的用户，本申请实施例对此不作限定。

本申请实施例中，运力指的是一个服务区域中的订单数量与该服务区域中的待接单用户数量的供需关系，其中，如果一个服务区域中的待接单用户的数量与订单数量相近时，则认为该服务区域的运力平衡；如果一个服务区域中的待接单用户的数量远大于订单数量时，则认为该服务区域的运力富余；如果一个服务区域中的待接单用户的数量远小于订单数量时，则认为该服务区域的运力不足。

本申请实施例中，可以通过统计目标服务区域中的订单数量与该服务区域中的待接单用户数量，来达到检测该目标服务区域的运力情况的目的。

本申请实施例中，可以实时检测目标服务区域的运动情况，也可以预先设置一定的触发条件，只有当满足预设的触发条件时，才开启检测目标服务区域的运动情况，具体的，当检测到发生预设类型的事件时，检测目标服务区域的运力是否不足，其中，该预设类型的事件可以包括下述至少一种：预设类型的天气、上下班高峰期、重大节日或会议事件。

本申请实施例中，预设的天气类型可以包括：雨、雪、大风、雾霾或冰雹等一些可能会影响交通的恶劣天气，重大节日可以包括：国庆节、五一等人们集中出行的节日。可以理解，预设的突发事件还可以是其它的事件，例如明星的演唱会等，本申请对此不作限定。

通常情况下，预设类型的事件发生后，会对一些服务区域的交通造成一定的影响。例如，当预设类型的事件为上下班高峰期时，写字楼分布较多的服务区域的交通状态会比较拥堵。

本申请实施例中，可以从气象局的网站或网络上获取当前的天气信息，根据当前的天气信息判断当前的天气是否为预设类型的天气，如果当前的天气为预设类型的天气，则确定发生了预设类型的事件。此外，可以获得当前的时间信息，根据当前的时间信息判断当前是否为上下班高峰期、或者重大节日等等。

本申请实施例中，目标服务区域的备选服务区域可以包括：目标服务区域周边的任一服务区域、目标服务区域周边的任一运力富余的服务区域、或者人为规定的服务区域，本申请实施例对此不作限定。

本申请实施例中，在网络约车场景下，处于备选服务区域中的待接单用户指的是当前所处位置位于备选服务区域内的司机，在外卖配送场景下，备选服务区域中的待接单用户指的是配送范围处于备选服务区域内的配送员。

本申请实施例中，可以通过向待接单用户的终端设备中安装的第三方o2o服务软件发送调度消息，来实现向该待接单用户发送调度消息。在网络约车场景下，终端设备中安装的第三方o2o服务软件可以为地图软件或网约车司机端软件。在外卖配送场景下，终端设备中安装的第三方o2o服务软件可以为外卖软件。

本申请实施例中，当向待接单用户的终端设备中安装的第三方o2o服务软件发送调度消息后，该第三方o2o服务软件可以在该服务软件的当前用户界面上以弹窗或卡片的形式展示调度消息的内容，并提供用户输入反馈信息的接口。

本申请实施例中，通过向处于备选服务区域中的待接单用户发送调度消息的方式，来询问该待接单用户是否同意接受o2o服务系统的调度。

订单推送模块320，用于在从所述待接单用户接收到同意前往所述目标服务区域接单的回答时，向所述待接单用户推送所述目标服务区域中的订单。

本申请实施例中，待接单的用户做出的回答可以包括：接受o2o服务系统的调度，即同意前往目标服务区域接单；或者拒绝o2o服务系统的调度，即拒绝前往目标服务区域接单。

本申请实施例中，当确定备选服务区域中的待接单用户接受o2o服务系统的调度时，只向该待接单用户派发目标服务区中的订单。

一般，o2o服务对应的订单中通常包括起点和终点，例如，在网络约车场景下，订单为出行订单，该出行订单中包含乘客指定的上车点(即起点)和指定的下车点(即终点)；又例如，在外卖配送场景下，订单为外卖订单，该外卖订单中包含商家的地址(即起点)和点餐的顾客的地址(即终点)。提供服务的用户在提供服务的整个过程中，其活动轨迹至少需要覆盖该起点或终点，本申请实施例中，向待接单用户推送的订单的起点、和/或终点应该处于目标服务区域中。

具体的，可以先获得o2o服务系统中待分配的订单，获得各待分配的订单的起点和终点，之后查找出起点、和/或终点处于目标服务区域中的订单，最后，将查找到的订单推送给接受系统调度的待接单用户。

以网络约车场景为例，下班高峰期，西二旗服务区域的出行订单的数量很大，但是可用网约车的数量很少，而上地服务区域的可用网约车数量很多，此时，网约车服务系统向处于上地服务区域中的司机发送调度消息，在该司机接受调度后，网约车服务系统只向该司机推送起点或终点处于西二旗服务区域的出行订单。

由上述实施例可见，该实施例中，当目标服务区域的运力不足时，可以调度其他服务区域中的待接单用户前往该目标服务区域，并只向待接单用户派发该目标服务区域中的订单，从而实现了将服务资源集中到服务需求量更大的服务区域，因此，减少了服务资源的浪费。

为了保证备选服务区域中的运力能够满足该备选服务区域中的服务需求量，在本申请的一个实施例中，目标服务区域的备选服务区域指的是运力富余的服务区域。

本申请实施例中，可以从目标服务区域周边的服务区域中筛选备选服务区域，也可以从大数据处理的角度分析出历史时间内运力始终富余的服务区域，将该运力始终富余的服务区域作为备选服务区域，本申请实施例对此不作限定。

为了确保o2o服务的服务效率，例如，应答速度，本申请实施例中，可以优先考虑从目标服务区域周边服务区域中选择备选服务区域，图4是根据本申请一示例性实施例示出的另一种订单分配装置的框图，该实施例可以在图3所示实施例的基础上，如图4所示，所述装置还可以包括：备选区域确定模块410，其中，所述备选区域确定模块410，可以包括：

运力情况获得子模块411，用于在检测到目标服务区域的运力不足的情况下，获得所述目标服务区域周边服务区域的运力情况；

备选服务区域确定子模块412，用于将所述周边服务区域中运力富余的服务区域确定为备选服务区域。

一般，相较于非周边服务区域，目标服务区域周边服务区域中的待接单用户在接受调度后，可以更快地到达目标服务区域。

本申请实施例中，可以将目标服务区域周边服务区域中运力富余的一个或多个服务区域确定为备选服务区域，本申请实施例对此不作限定。

由上述实施例可见，该实施例中，可以从目标服务区域周边服务区域中选择备选服务区域，由于相较于非周边服务区域，目标服务区域周边服务区域中的待接单用户在接受调度后，可以更快地到达目标服务区域，因此可以提高o2o服务的服务效率。

图5是根据本申请一示例性实施例示出的另一种订单分配装置的框图，该实施例可以在图3或图4所示实施例的基础上，如图5所示，所述订单推送模块320，可以包括：

服务时段确定子模块321，用于根据设定的服务时长、以及待接单用户接受调度的时间点和待接单用户到达所述目标服务区域的时间点中的任一时间点，确定所述待接单用户的服务时段；

一般，服务区域的运力不足情况在一段时间后会有所缓解或运力恢复平衡状态，此时，可以不必再从备选服务区域调度运力，因此，本申请实施例中，可以确定一定的服务时段，在该服务时段内向待接单用户推送目标服务区域中的订单，而当超出该服务时段时，采用平时的派单策略向待接单用户推送订单。

本申请实施例中，可以根据设定的服务时长和待接单用户接受调度的时间点，计算该待接单用户的服务时段，例如，设定的服务时长为δt，待接单用户接受调度的时间点t0，那么，待接单用户的服务时段为(t0,t0+δt)。

或者，本申请实施例中，可以根据设定的服务时长和待接单用户到达目标服务区域的时间点，计算该待接单用户的服务时段，例如，设定的服务时长为δt，待接单用户到达目标服务区域的时间点t1，那么，待接单用户的服务时段为(t1,t1+δt)。

订单推送子模块322，用于在所述服务时段内向所述待接单用户推送所述目标服务区域中的订单。

本申请实施例中，当根据设定的服务时长和待接单用户接受调度的时间点确定服务时段时，在服务时段内，当待接单用户到达目标服务区域之前，只向该待接单用户推送终点处于目标服务区域中的订单，当待接单用户到达目标服务区域之后，只向该待接单用户推送至少起点处于目标服务区域中的订单。

或者，本申请实施例中，当根据设定的服务时长和待接单用户到达目标服务区域的时间点确定服务时段时，在服务时段内，只向该待接单用户推送至少起点处于目标服务区域中的订单；此外，当待接单用户到达目标服务区域之前，可以不向该待接单用户推送任何订单，或者只向该待接单用户推送终点处于目标服务区域中的订单。

由上述实施例可见，该实施例还可以只在服务时段内才向待接单用户推送目标服务区域中的订单，在服务时段之外不向待接单用户推送目标服务区域中的订单，因此，可以避免将服务资源长时间内集中在一个服务区域中，从而避免服务资源的浪费。

为了避免o2o服务系统大量地将其他服务区域中的运力调度到目标服务区域，造成目标服务区域中的运力过剩，导致服务资源的浪费，图6是根据本申请一示例性实施例示出的另一种订单分配装置的框图，该实施例可以在图3～图5所示任一实施例的基础上，如图6所示，所述装置还可以包括：

用户数量获得模块610，用于获得同意前往所述目标服务区域接单的待接单用户的数量；

控制模块620，用于在所述用户数量获得模块610获得的数量大于设定的数量阈值的情况下，停止向所述备选服务区域中的待接单用户发送调度消息。

本申请实施例中，在设置设定的数量阈值的取值时，以可以保证目标服务区域中的运力平衡为标准对该数量阈值的取值进行设置。

由上述实施例可见，该实施例中，可以通过控制调度到目标服务区域内待接单用户的数量，来避免o2o服务系统大量地将其他服务区域中的运力调度到目标服务区域，造成目标服务区域中的运力过剩，导致服务资源的浪费的情况的发生。

图7是根据本申请一示例性实施例示出的另一种订单分配装置的框图，该实施例中，如果接受调度的待接单用户在规定时间内到达目标服务区域，则向该待接单用户发放一定的奖励，此时，该实施例可以在图3～图6所示任一实施例的基础上，如图7所示，所述装置还可以包括：

判断模块710，用于在从所述待接单用户接收到同意前往所述目标服务区域接单的回答的情况下，判断所述待接单用户是否在规定时长内达到所述目标服务区域；

奖励发放模块720，用于在所述判断模块710的判断结果为是的情况下，向所述待接单用户发放奖励。

图8是根据本申请一示例性实施例示出的另一种订单分配装置的框图，该实施例可以在图3～图7所示任一实施例的基础上，如图8所示，所述装置还可以包括：

检测模块810，用于在检测到发生预设类型的事件的情况下，检测目标服务区域的运力是否不足。

本申请实施例提供的另一种实施例中，该实施例可以在图8所示实施例的基础上，所述预设类型的事件可以包括下述至少一种：

预设类型的天气、上下班高峰期、重大节日或会议事件。

本申请实施例中，也可以预先设置一定的触发条件，只有当满足预设的触发条件时，才开启检测目标服务区域的运动情况，具体的，当检测到发生预设类型的事件时，检测目标服务区域的运力是否不足，其中，该预设类型的事件可以包括下述至少一种：预设类型的天气、上下班高峰期、重大节日或会议事件。

本申请实施例中，预设的天气类型可以包括：雨、雪、大风、雾霾或冰雹等一些可能会影响交通的恶劣天气，重大节日可以包括：国庆节、五一等人们集中出行的节日。可以理解，预设的突发事件还可以是其它的事件，例如明星的演唱会等，本申请对此不作限定。

通常情况下，预设类型的事件发生后，会对一些服务区域的交通造成一定的影响。例如，当预设类型的事件为上下班高峰期时，写字楼分布较多的服务区域的交通状态会比较拥堵。

本实施例中，可以从气象局的网站或网络上获取当前的天气信息，根据当前的天气信息判断当前的天气是否为预设类型的天气，如果当前的天气为预设类型的天气，则确定发生了预设类型的事件。此外，可以获得当前的时间信息，根据当前的时间信息判断当前是否为上下班高峰期、或者重大节日等等。

上述装置中各个模块的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

本申请实施例还提供了一种计算机存储介质，所述存储介质中存储有程序指令，所述程序指令包括：当检测到目标服务区域的运力不足时，向处于所述目标服务区域的备选服务区域中的待接单用户发送调度消息，其中，所述调度消息用于请求所述待接单用户回答是否同意前往所述目标服务区域接单；当从所述待接单用户接收到同意前往所述目标服务区域接单的回答时，向所述待接单用户推送所述目标服务区域中的订单。

本申请实施例可采用在一个或多个其中包含有程序代码的存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。计算机可用存储介质包括永久性和非永久性、可移动和非可移动媒体，可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括但不限于：相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。

如图9所示，图9是本申请实施例根据一示例性实施例示出的一种用于订单分配装置900的一结构示意图。例如，装置900可以被提供为一服务器。参照图9，装置900包括处理组件922，其进一步包括一个或多个处理器，以及由存储器932所代表的存储器资源，用于存储可由处理部件922的执行的指令，例如应用程序。存储器932中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理组件922被配置为执行指令，以执行本申请实施例提供的订单分配方法，该方法包括：当检测到目标服务区域的运力不足时，向处于所述目标服务区域的备选服务区域中的待接单用户发送调度消息，其中，所述调度消息用于请求所述待接单用户回答是否同意前往所述目标服务区域接单；当从所述待接单用户接收到同意前往所述目标服务区域接单的回答时，向所述待接单用户推送所述目标服务区域中的订单。

装置900还可以包括一个电源组件926被配置为执行装置900的电源管理，一个有线或无线网络接口950被配置为将装置900连接到网络，和一个输入输出(i/o)接口958。装置900可以操作基于存储在存储器932的操作系统，例如windowsservertm，macosxtm，unixtm，linuxtm，freebsdtm或类似。

在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器932，上述指令可由装置900的处理组件922执行以完成本申请实施例提供的上述订单分配方法。例如，所述非临时性计算机可读存储介质可以是rom、随机存取存储器(ram)、cd-rom、磁带、软盘和光数据存储设备等。

本领域技术人员在考虑说明书及实践这里公开的公开后，将容易想到本申请实施例的其它实施方案。本申请实施例旨在涵盖本申请实施例的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请实施例未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请实施例的真正范围和精神由下面的权利要求指出。

应当理解的是，本申请实施例并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请实施例的范围仅由所附的权利要求来限制。