今天心血来潮突然想写点紧靠业务的文章，做了几年的配送业务，一直没有十分概括的看目前的工作，似乎今天突然想清楚啦。 并不是业务上有多么的精进，而是真的把这个业务能够与现实的生活关联起来，开窍的前兆啦。
找了好久终于找到一个像样的图片啦（如图1）。整个配送业务就是一个大的蓄水池系统。配送的最大目标就是让这个系统不要崩坏， 尽可能的稳定和高效的运行。所以就有几个系统需要维持整个配送蓄水池的健康运行（不溢出水，不干涸）。那么这个系统的高效的表现就是，尽可能短的时间内从入水口尽可能多的导出水。
供需系统
可以看出为了不让这个水桶溢出大量的水（订单）， 需要保证这个水桶的水位在安全线附近。 这就是供需系统最大的作用，所以供需系统在入水口的时候要进行管控（不仅控制水的流速，还要控制水的质量），纵观整个系统的安全，及时的做出停水动作，以及当水桶要干涸的时候要尽可能的从入水口接入更多的水源。当然这里还有一个重要的点就是安全水位的概念。供需要站在整个配送的系统的视角去看待安全水位。 或者是某种最优负载之类的指标。
当系统能力得到的很大的提升， 安全水位要上调，当系统的能力下降要适当的降低安全水位。从而是整个系统尽可能的健康的运行。
订单结构
从宏观视角， 供需的作用点到为止。但是实际上供需系统在整套系统中的角色远远不至于此。 实际的系统中， 这套系统中流入的不仅仅是水一种，可能是不同密度的液体(或者说水的质量)。 甚至是杂质。 对于下面的出水口而言， 流出水的能力是变化的， 当骑手全部空闲时，消化能力最大，随着水位的增加，下游的出水口开始对流出的水的质量有要求啦， 能够和当前正在流出的水一起流出的，不会影响流出速度，但是如果流入的水中杂质较多，那么会让整个流出速度更慢，直到系统崩溃。所以供需要在合适的时间流进来不同质量的水，让流出速度始终最快。
最后，通过一个形象的展示来说明订单结构的重要性吧， 左边的图表示好的订单结构，水都有秩序的进入到了桶里（订单不超时，且稳定），右边的水龙头瞬间变成花洒， 导致大量水流入到外边， 最终导致很少的水流入到桶里，大部分的水都流到外面变成了异常的订单。
感知原因
供需的另一个需要解决的问题是要对整个配送系统有感知有原因。实时的感知到系统面临的问题瓶颈是什么，要么自己控制水的流速，要么联动整个下游让系统效率最高。
履约系统
履约系统处于出水口的位置，代表着整个系统的消化订单的能力，这里经常有一点被忽略，随着骑手负载的增加（水位越来越高），履约系统的消化效率是会变低的。（当我身上已经有了一单，再配送一单往往是需要更长的时间）。 那么如何来看待履约系统的能力的好坏呢？ 从一个方面讲，履约系统要极致的优化效率，就是单位时间内要流出更多的水量。 一种是对异常杂质的鲁棒性。 供需是有可能在前面送进来格格不入的订单，导致履约系统整体效率被限制的很死。 履约系统本身要有对这种问题的取舍，极致的优化效率。
这里会再提到供需系统， 一个是安全水位要根据履约系统的能力做动态调整。 另一方面，要尽可能的少的放进来杂质。 这里需要解释一下， 随着骑手身上负载的变大，对订单的消化能力是变低的。这是一个宏观视角， 如果从更细的粒度看这个问题，其实是骑手对某个方向的订单的消化能力变低了。 这里就体现出了供需要对订单结构有感知。
压单
对于履约系统也有一些核心优化的点，压单是派单系统中常用的一个动作，虽然看起来是让水流出，但是站在实时的视角，流出的顺序就变得异常重要，可能某些单先流入进来，但是如果马上就让订单流出，可能就浪费了一个骑手，留在队列里流转一段时间后，合并成本流出往往是更好的选择。当然这里有一个十分难的点，压单本身也是一种损失， 所以压单应该优化的是，压单带来的配送时长的增加和合单以后带来的效率的提升的平衡。
这里本身也是几个视角去看待优化动作的。 当我处于分单的那一刻，我的优化点是保持这些订单池的订单配送效率最优。 下个阶段就变成了，这10min 我是不是还有优化空间，这里就是从压单这个动作拿来的。进一步找到那些时空需要有这种优化动作。
收益来源
- 低效匹配转化为高效匹配
- 单飞订单转化为合单订单
- 多单配送，效率最优。