Home  /   最新动态  /   行业资讯  /  

拼车日滴滴派单的那些事(转载)

2020-04-01 10:39:19     行业资讯

2019年11月29日,在滴滴拼车上线4周年之际,滴滴发布全新的拼车产品,同时宣布2019年12月3日在北京、上海、广州、成都等26个城市推出拼成一折的活动,打造首个“全民拼车日”。面对类似双11的一折促销活动,如何应对瞬间的流量峰值,以及平滑、高效的实现司乘撮合,本文就滴滴的派单引擎来阐述这些问题的解决思路。


 0.

目录

  


  1. 背景

  2. 滴滴分单架构概述

     ○ 分单模式

     ○ 滴滴分单架构

  3. 拼车日带来的挑战

     ○ 拼车原生属性

     ○ 拼成出发预约模式

     ○ 服务化架构

  4. 稳定性保障之路

     ○ 架构优化

     ○ 拼成出发预约模式 - 临近指派

     ○ 过滤逻辑优化 - 架构与性能的折衷

     ○ 超时重试配置化

     ○ 预案建设

     ○ 全链路压测

     ○ 监控告警

     ○ 告警

     ○ 监控

     ○ 集中值班

     ○ 通报机制

     ○ 快速决策方案拟定

  5. 展望

      背景

     11月29日,在滴滴拼车上线4周年之际,滴滴发布全新的拼车产品。同时宣布12月3日将在北京、上海、广州、成都等26个城市推出拼成打一折的活动,打造首个“全民拼车日”。

     拼车推出新模式“拼成出发”和拼成打一折的活动给分单引擎带来成倍的压力增长,本文介绍其中的挑战。


     滴滴分单架构概述

     滴滴分单引擎主要做的是司机和订单的匹配,也就是来决策如何更好的将用户的订单分配给司机。

     ▍分单模式

     从分单模式上,主要抽象为独乘分单和合乘分单(拼车分单):

  

网约车牌照申请_网约车系统开发_共享汽车系统开发_城际车系统开发_跑腿系统开发_货运系统开发_城际车系统开发


     独乘分单解决的是单个订单和司机的最优决策分单,分为多种场景模式,目前承载了滴滴快车、专车、出租车、豪华车的独乘分单业务。

     对于拼车单,会将顺路的订单进行打成一个“包”,在独乘分单的基础上,拼车分单还要解决“包”和司机的最优决策分单,承载了目前快车拼车、出租车拼车、跨城拼车的合乘分单业务。

     ▍滴滴分单架构

     分单整体流程如漏斗,订单司机对会从顶层,层层向下筛选,最终形成一个个可匹配的订单司机对。

  

网约车牌照申请_网约车系统开发_共享汽车系统开发_城际车系统开发_跑腿系统开发_货运系统开发_城际车系统开发


    假设参与计算的订单有1000,司机有4000,那么进入第一层的订单司机对数是400万,计算压力与订单数和司机数的乘积成正比。

    ③拼车日带来的挑战

    滴滴分单引擎主要做的就是司机和订单的匹配,所以司机订单匹配计算量基本上表征了整个系统的压力。

    活动当天:司机订单匹配计算量峰值相比日常峰值增长2.24倍,其中拼车计算量相比日常峰值增长6.6倍。

    总结下来主要是以下几方面的原因:

    ▍拼车原生属性

    对于一个普通的快车单来说,分给一个司机之后,在这个司机快到达目的地之前,这个司机可以认为不参与分单了,对于系统压力变小。

    但是对于一个拼车单来说,分给一个司机之后,这个司机会继续进到分单系统里面来,和别的拼车单执行“拼”的逻辑,所以相比于快车单,司机的匹配周期更长,计算也更复杂,除了考虑司机和乘客的匹配外、还需要考虑乘客和乘客的顺路度。

    ▍拼成出发预约模式

    在正常情况下,一个快车单的生命周期只有有限几分钟,生命周期内没应答,就会自动取消,那么系统就没有压力了。

    拼成出发,分为随时可走和预约模式,预约模式最长生命周期1天,虽然初期预约单占比不高,但随着时间推移,预约单越堆积越多,系统压力越来越大。

    拼成出发只能分配载人车,或者作为一个包分给司机,本身条件就更苛刻,在订单池里面的存活时间也更长一些。

    总结来说,拼成出发模式使得订单的生命周期更长。

    ▍服务化架构

    目前的司机订单过滤架构简化图如下:

  

网约车牌照申请_网约车系统开发_共享汽车系统开发_城际车系统开发_跑腿系统开发_货运系统开发_城际车系统开发


    整体分单流程是一种漏斗形式,输入是需要匹配的司机和订单,输出是匹配成功的匹配对。

    第一层漏斗是通用过滤层,对于通过了通用过滤模块的司机订单组合,才会漏到拼成过滤层进行过滤。

    无论是通用过滤模层还是拼车过滤层,都是先进行过滤,对于没有被过滤的司机订单组合,再进行访问下游的工作。

    对于在2.1部分过滤的司机订单组合来说,在1.2部分访问的下游数据很多是无用的,也就是说给下游带来的压力是浪费的,这也是服务化架构引入的代价。

    拼成出发模式因为拼成了才能派车,而是否可以拼成的逻辑都在拼车过滤模块中,随着时间的积累,能通过1.1但是无法通过2.1的司机订单组合越来越多,这也是下游压力增长过大的一个原因。

    稳定性保障之路

    我们的稳定性保障工作主要分为架构优化、容量评估、预案建设、监控告警、全链路压测几个部分:

    ▍架构优化

    我们对现有架构进行了审视:

    其中拼成出发预约模式和服务化架构引入的代价部分,给下游带来的压力过大,不能完全按照现有模式进行扩容,我们需要对现有架构进行优化。

    拼成出发预约模式 - 临近指派

    针对拼成出发预约模式,用户发单之后,订单会同时进入分单的订单池和拼车的拼友池。拼友池:进入拼友池的订单,拼车打包模块会给当前用户寻找拼友,也就是进行打包操作。

    订单池:进入订单池的订单,就会进入分单引擎进行分单。但拼成出发预约模式,会在订单出发时间的前k分钟,才真正开始给用户找车,在找车之前的计算都是无效的。

    针对这种情况,对拼成出发预约模式进行了优化,将发单进入订单池的操作改为临近进入订单池,有效降低订单池规模。

    过滤逻辑优化 - 架构与性能的折衷

    针对服务化架构引入的代价,拼车分单的同学将拼车过滤中过滤比例较高的策略,迁移到了通用过滤模块中。这算是在现有架构下,为了性能的一种妥协。

  

网约车牌照申请_网约车系统开发_共享汽车系统开发_城际车系统开发_跑腿系统开发_货运系统开发_城际车系统开发


    后续应该会探讨出一种更合理的架构来解决这种问题。

    经过评估,上面2部分的业务架构优化,在同样用户呼叫单量的前提下,对下游的访问压力可以下降50%以上。

    超时重试配置化

    为了更加灵活的控制下游的超时重试,整个分单主流程的调度周期,下游的超时时间,重试次数,都实现了配置化,修改秒级生效。

    为了防止流量突增时引发下游雪崩,在拼车日之前,我们将整个分单主流程的下游重试都调成了1,也就是不再重试。

    ▍预案建设

    因为活动中可能会有很多不可预知的事情发生,针对可能发生的异常,我们做了一系列的预案。

    预案的底线目标是:保障评估容量内无异常,超出评估容量不被打挂;包括五部分:

    提前降级功能:活动前操作,主要提前降级的功能

    入口预案:活动中操作,出现重大风险和异常时执行

    最小核心链路预案:活动中操作,核心节点出现风险和异常时执行

    业务指标异常预案:活动中,系统无异常,但是业务指标出现异常

    崩溃恢复预案:核心服务出现雪崩,如何快速恢复

    每项预案都需要提前演练,保证预案有效、且符合预期。

    ▍全链路压测

    全链路压测是评估系统容量最有效的手段,拼车日一共进行了8次演练,9次正式压测,发现了45个有效问题。

    经过一轮又一轮的压测,大家对自己的服务容量都有了更清晰的认识。

    在压测过程中,到达系统容量之后,我们还会继续加压,观察多个系统在系统超限情况下,是否会被打挂。

    在压测过程中,我们也会演练提前制定好的预案,把压测场景当成活动日看待。

    ▍监控告警

    告警

    拼成日之前,我们重新梳理了各模块告警。分以下几大类:

    机器信息类:包括cpu、磁盘、句柄数、网卡错误、协议栈错误

    自身服务:包括存活性、服务容量水位线、服务总耗时最大值、服务各阶段耗时最大值

    依赖服务:包括请求耗时、超时或者错误率、是否限流

    client端:请求耗时99分位、成功率

    同时对于各个告警都进行了报警升级,拼车日当天宁可误报,不可错过任何一个错误信息。

    针对每个告警,都有至少一个预案阈值对应,保证系统稳定性。

    监控

    除了完善系统各项指标监控,我们还建立了多个监控大盘。

    拼车业务指标大盘:各个指挥者需要实时关注该大盘。

    系统机器性能大盘:运维人员需要实时关注该大盘。

    各个服务监控:为每个服务指定负责人,实时关注。

    ▍集中值班

    通报机制

    各个方向值班长需要在值班群里实时通报异常情况。

    每隔10分钟,各个方向值班长需在值班群里通报系统是否正常。

    快速决策方案拟定

    拼车日之前,已经确定好。遇到何种问题需上报,何种问题需立即快速解决,何种问题需上下游配合解决。解决方案要尽可能得覆盖异常情况。

    我们采用了扁平化的人员组织方式,以达到更高效率的问题处理。

  

网约车牌照申请_网约车系统开发_共享汽车系统开发_城际车系统开发_跑腿系统开发_货运系统开发_城际车系统开发
    展望

    拼车相对于快车对系统在匹配复杂度、路径规划等方面的挑战更大,难度更大,基于这次拼车日保障的积累,我们将不断提升能力,提供稳定可靠的技术保障。

    文章来源:滴滴技术

标签: