文章内容来自互联网，不做好坏评价。只对相关技术做以梳理、总结、学习。
总结技术内容之前，先看看这种“分单引擎”是应用在什么样的场景中的，并提出问题。
首先，它应用在一个平台之上，平台粘合与匹配了多方的需求（Uber/滴滴 -- 乘客与司机，外卖 -- C端用户、商家与骑手）。平台以积极构建网络效应为目的 -- 需求越多，供给就越多。
其次，越大的规模，越有助于平台来优化需求与供给之间交互的价值单元，如，Uber/滴滴对于乘客提供更短时间接乘的司机；外卖对于用户提供配送时效更短和更好服务体验的骑手，而这也是平台的价值。平台通过收集乘客的需求数据（包括，历史上这个区域的数据），司机的数据（车型、位置、速度等），并帮助过滤和筛选最优的司机来满足乘客的需求。
第三，在平台之上，随着规模的增大，网络效应会发生变化。准确的说，需要构建积极的网络效应，而持续不断的调节消极的网络效应。比如，更多的乘客打车需求会带来司机接乘时间的变长，从而又使得乘客的体验下降。近些年滴滴推出的 -- 快车、专车、顺风车、拼车等等模式，无不是通过不断的调整产品和运营策略以调节供需之间的平衡在做努力，细分并开拓更多的场景，以满足需求。不同的需求与供给，对于后端的分单引擎来说，带来的是调度模式和策略的复杂化、计算量的指数增长。
第四，“分单引擎”面对的不是一次只求解“单一需求与单一供给匹配”的最优解问题，而是“多个需求与多供给匹配”之间的全局的最优解问题。这里面的优化目标，不仅需要考虑某一个时刻乘客的体验问题（如，接乘时间指标、平台响应时间（有司机接单）指标），也要考虑司机的情况（价格等指标），以及未来一段时间内其他更多乘客和司机的需求供给匹配的问题，即：站在全局视角，尽量去满足尽可能多的出行需求，保证乘客的每一个叫车需求都可以更快更确定的被满足，并同时尽力去提升每一个司机的接单效率，让总的接驾距离和时间最短。
仔细拆解问题来看，这里面又分为如下一些问题：
（从算法策略角度 & 问题规模 - 如果考虑全国的规模，每次匹配几千乘客与司机，每天几千万单）
- 是否单单匹配？如果不是，而进行批量分单匹配的话，先拿出哪些乘客订单进行匹配？多久匹配一次？并以多大的batch size进行乘客订单和司机进行匹配？
- 打分和分派，如何考虑业务约束。比如，等级高的司机比较等级低的司机有更多的派单机会；某类司机只接某个区域范围内的单；特定场景下，乘客单可以在不同司机类别之间跨层转（快车单给专车）；
（从系统角度）
- 在匹配计算时，分单引擎所使用的机器资源该如何分配？全国的订单一起匹配？还是按城市/地理区域错开进行匹配？
- 匹配时，所需要的数据和计算任务量，该以哪种计算模型计算才能更好的利用资源？
- ... ...
上述要点都是关键的问题，其背后也隐藏着诸多其他相关复杂的制约和影响因素（如性能指标、资源利用率、系统稳定性、数据的一致性和正确性）。待后续不断的拆解，补充。
