你的外卖为什么他来送——聊一聊外卖订单的生命周期

一、基础概念

---

外卖系统：实现订单的收集、派单的系统

出餐时间：一个餐品的制作时长

接单上限：一个骑手能够一次配送的最大订单数量

ETA：预计送达时间

Pick and delivery problem：路径规划问题，其中货物或乘客必须从不同的起点运输到不同的目的地

二、习以为常的问题

---

• 手机上看到的配送时间是怎么来的？在外卖系统中有什么用处？
• 从下单到配送完成，你的外卖订单都存在哪些状态？
• 你的订单是抢单还是系统派单，你认为哪一种更好呢？

三、订单逻辑

---

外卖是我们日常生活常见的一个元素，那不知道大家有没有想过，为什么你的外卖由他/她来送？或者如果从同一个商家每天重复下单，是否会是同一个骑手配送？还有就是订单和骑手是如何匹配上的？这些问题可能从未出现过在大家的脑海，也可能只是一闪而过，饥饿的肚子抢占了最高优先级，其他的念头没有了一席之地。不管如何，今天我们来聊一聊外卖订单和骑手之间是如何匹配上的。

整体流程

---

我们从手机各种 app 或者小程序上，选中自己想吃的餐品后，在支付后就产生了一个外卖订单，那一个外卖订单的完整生命周期（下单-送达）【不考虑异常情况，例如售后、退换货等】中，背后都有哪些我们不为人知的事情呢，我们一一分析来看。

商家接单

---

首先，用户进行下单支付后，不是立即进行骑手的匹配的。我们经常看到一个提示信息『商家已接单』，代表的是商家侧接受了你的订单，当然，绝大多数商家都是设置的自动接单，既然商家绝大多数都是自动接单，那为什么需要这个环节呢？一是防止爆单，通过手动关闭接单来达到不在接受订单的状态，一个是缓存的作用，允许商家在订单过多时候，手动接单来获取更长时间制作餐品，类似于队列的排队等待状态。

抢/拍订单

---

系统在积累了一定时间后，有了一定量的订单了，这时候会开放订单池（即积累的待派订单），那如果直接将这些订单开放给骑手，遵从骑手的主观意愿，让骑手进行抢单从而实现和订单的匹配，是否可行呢？首先从订单角度看，会导致优质订单秒没，劣质订单超时的现象，或者换个说法就是挑单；然后从骑手角度看，带来骑手感官的不平衡，不利于骑手生态的管理，因为骑手不知道什么时候有订单以及下一个可能订单是否是优质订单，进而会对配送过程产生不满。也就是说，全局抢单模式对任何外卖系统的任意一方都不是有利。那抢单的模式就毫无价值可言嘛？那倒也不是。抢单是派单模式的补充，可以作为一种运营手段丰富系统的能力。目前而言，出行、外卖、快递等系统都不是单一的派单或抢单，而是两者的混合。毕竟没有最优，只是相对而言。

骑手匹配

---

终于到了骑手的匹配，这个阶段，我们就可以看做是骑手的召回阶段，那么你们觉得是从全量骑手来匹配嘛？我们知道搜索过程中，召回阶段是从海量（全量）物料中通过多路召回机制，筛选全集的一个候选子集，那么你们觉得骑手该如何召回呢？城市维度？城区维度？实际上，常用的召回是地理单元格集合维度（Geohash【正方形】/H3【正六边形】），即以特定点所在经纬所属的单元格开始，所有近邻的单元格的合集是召回的子集，也存在多路召回的情况，本文不做讨论了。以下图为例，WX4G0是起点，周围相邻八个单元格和 WX4G0构成了召回的全部单元格集合（H3索引是7个）。那你们觉得起始经纬度坐标，是用户坐标还是商家坐标呢？一般来说是商家坐标作为起点，使得骑手到商家的距离较近。到目前位置，我们知道了所有的初始候选骑手，那么对于一个订单而言，该选择哪个骑手合适呢？实现骑手和订单的匹配过程，又需要考虑什么问题呢？

订单能否分配给一个骑手，可能要考虑的因素有骑手自身、商家、用户侧以及其他可能因素，例如天气、交通等。骑手和订单的匹配过程犹如九九八十一难，是一个不断缩小的过滤漏斗，从已知的各种条件和运营手段上，对候选骑手进行筛选，最终达到一些或者一个骑手的目的。

首先，在下单前的商家列表页上，有的标识为『蓝骑士专送』而有的没有，甚至出现肯德基、麦当劳等专送骑手的情况，那订单产生后，候选骑手的一个过滤漏斗即是否需要有特定群体的需求。其次，假定我们从骑手的角度考虑，如果骑手身上订单已满（达到骑手的允许接单上限）或剩余额度不满足当前订单所需（并单、大单、超重等），那么这类骑手应该排除再外，可能订单侧有不同的要求时，对骑手的过滤会有不同的情况，例如贵重订单要求一定等级的骑手、特定区域的订单要求地区比较熟悉的骑手等等。

当然，在具体的系统中，肯定还存在各种各样的筛选条件，对召回的骑手进行各种各样的过滤从初始召回的群体中，进行不断的过滤筛选，从而达到一个较小的最终集合。可能同学有疑问，不进行层层的过滤，将这些条件转换为特征，进行端到端的输出不可以吗？可能还真不如这样层层过滤的效果，我们分析来看，首先系统的计算中会涉及到路线规划问题，是一个NP-Hard 问题，骑手数量过多的时候，计算复杂度是难以接受的；再者，匹配过程是一个掺杂运营手段的过程，和临时性的业务逻辑耦合，难以抽象统一规范的特征。

订单生命周期

---

在外卖订单的生命周期中，时间是唯一的指标，所有因素都会折算成一定的耗时情况来考虑。我们都知道时间=距离/速度，但这里的『距离』和『速度』是折合了各方因素后逻辑表达。以距离为例，计算方式有两点之间的直线距离，也有实际的地图距离，甚至还可以拆分为骑行、步行距离等。时间维度上也会根据实际情况进行转换叠加，例如早午高峰时其他条件相同情况下，配送时间会变长。天气、节假日、交通状况等等，都可以作为直接转化时间或特征输入模型，来影响最终的配送时长。

那在外卖系统中，存在的各种时间是如何相互制约的呢？首先，用户下单后呈现的预计送达时间，是系统结合当前状态给出的估计时间，此时可以没有骑手的因素而用历史平均状态来代替，这个时间（用户 ETA）是呈现给用户侧的，是全局最重要的时间。然后，在进行骑手的筛选过程中，出现第二个重要性时间：骑手预计配送时间（骑手 ETA），该时间代表了骑手系统综合当前状态（骑手、商家、外界以及订单）进行的预估时间。很明显，骑手的 ETA 要小于等于用户的 ETA 才能够满足用户订单的准时送达，实际中是允许进行一定范围的波动（±α time）。

外卖系统是一个强时间状态的系统，对于时效性的要求非常高，而现实世界中是通常存在各种意外的，例如地图定位不准、商家出餐太慢、骑手错误估计配送顺序等。这些意外情况通常需要一定的时间来处理，为了防止意外的发生，可能需要进行提前时间量的预留，从上面的时间状态中，我们可以看出，存在压缩空间的地方只有骑手ETA。

参考链接：

https://www.movable-type.co.uk/scripts/geohash.html
https://blog.csdn.net/weixin_46991173/article/details/113806214