司机为什么会在异地接单
在正常的派单场景下，司机只会在其归属城市所在地接单，不会去异地城市接单。原因：
- 司机的家就在归属城市，去到异地后，司机的生活成本就要增加。
- 不同城市的交通管制政策不同。司机的证件在归属城市是合规司机，但是在异地城市就不一定合规；再加上，不同城市会限制异地司机的牌照；司机去异地接单会受到各种约束。
既然如此，那么在什么场景下，司机会去到异地城市呢？
- 正好有跨城订单，并且价格合适，司机服务乘客去到异地。
- 司机的家正好在城市交界处，经常要在两个城市之间来回切换。
- 司机在归属城市打工，到了春节或者国庆，这些大的节假日，需要开车回到老家。在司机的休息期间，他也愿意在老家进行接单服务。
司机在异地接单的策略
基于不同城市的交通管制策略，司机去到异地城市后，存在两种接单策略：
- 司机归属城市和实际所在城市，两个城市的交通管制策略相同，司机可以在异地城市的部分区域进行接单服务。
- 司机归属城市和司机所在城市，两个城市的交通管制策略不相同，司机只能接从异地城市返回的订单，防止司机空跑回来。
司机位置的管控方式
在网约车平台上，司机的位置数据是技术管控难度较大的点。原因有：
- 司机的数据量较大，位置数据需要进行实时更新，位置更新的QPS较大。
- 依赖司机位置数据的业务方较多，比如：派单召回司机，查询周边的运力情况等等，查询司机位置的QPS也较大。
司机位置数据的存储数据库，整体的数据量较大，支持高并发的写入和查询。
- 司机整体的数据量: 1000w
- 数据更新的QPS: 50w； 数据查询的QPS: 100w
这个实时数据，在整个网约车业务系统中都非常关键，一旦缺失，会导致整个网约车业务系统崩盘。所以，这个数据库存储要保障好两点要求：
- 数据库要保障好稳定性。在大并发的情况下，数据库要能够正常运行，不能出现宕机。
- 数据库要保障好性能。在大并发的情况下，更新和查询的耗时不能过高，要确保业务的性能达到要求。
基于数据量、高并发、高性能的要求，这个数据库的设计就要考虑如下几点：
- 对司机的管理，基于城市分库分表，分流处理整体大的数据量和并发流。
- 建立好索引，提升查询效率。
异地派单的方式
当前现状，先判定下单城市存在哪种异地接单策略。
- 如果，只存在让异地车辆接返还订单的策略。那么，先判定订单是否为跨城订单：
- 不是： 走正常派单流程即可
- 是： 按照下单城市和异地城市，基于下单位置召回可用运力
- 如果，只存在让异地车辆接本地订单的策略。那么，所有的订单都需要从多个城市去召回运力。
- 如果，两个策略都存在。所有订单也需要从多个城市去召回运力。
- 如果，两个策略都不存在。只走本地城市正常的运力召回。
当前的现状，这种方式存在什么问题呢？
由于司机的数据是按照城市分库分表的，不同城市的司机各自独立管理。通过这样的分流方式，解决了整体的并发压力，但是又引入了另一个问题。
司机一旦从归属城市跨到另一个异地城市，司机的位置数据如果还在归属城市管理，这样就会导致异地城市的订单，无法召回跨城的司机。
如果要召回这样的司机，就要像上面说的那样，通过多个城市进行召回，从而会依赖多个城市的运力数据库，最终导致当前城市的派单效率受限于多个城市的运力数据库。
如何解决呢？
司机一旦跨城，司机的位置数据进行双写。一份，更新到司机归属城市的数据库；另一份，更新到司机实际所在城市的数据库。
更新到归属城市所在的数据库，是为了解决司机在刚刚跨过城市交界时，能够让归属城市交界位置的订单需求，依然可以召回跨城的司机。
更新到司机实际所在城市的数据库，是为了解决上面提到的依赖多个城市运力数据库的问题。司机到了异地城市，派单时能够直接基于订单当前的位置，从订单归属城市召回周边多个跨城的司机。
这样司机在异地城市交界处时，既可以在异地城市派单，又可以在归属城市派单，从而会导致一个司机同时派到多个订单。
如何解决一车派多单的问题呢？
由于两个不同城市的派单各自完全独立，这个中间就需要增加一个互斥锁。
跨城并且处于城市交界处的司机是公共资源，两个城市在抢占同一个司机资源时，就要加锁进行互斥，确保一个城市的订单已经抢占了这个司机时，另一个城市就无法再抢占，必须等到前一个城市把资源释放。
结尾
以上介绍了如下几点：
- 司机为什么会异地接单的背景。
- 司机异地接单的策略。
- 司机异地接单的技术挑战，是因为司机位置管控的技术难度较大。
- 司机如何进行异地接单的。
