共计 887 个字符,预计需要花费 3 分钟才能阅读完成。您也可以 收藏到微信
一、方法特征
本方法旨在通过实时判断市场供需情况,动态调整播单策略,从而在“高并发”和“低并发”两种场景下实现预约单派发效率的最优化。
二、方法流程
S1:接收订单与初步筛选
乘客在打车软件下达预约订单。
网约车派单平台根据订单信息(目的地 、 预约用车时间 、 所选车型)初步筛选出当前空闲、可接收播单的司机群体。
S2:实时市场数据请求
网约车算法模型系统向大数据平台发出请求,要求获取 该城市过去 X 分钟内,该车型的实际下单量或派单量 Y 。
S3:实时数据计算与返回
大数据平台接收请求后,实时调取订单数据库进行计算。
将计算得出的订单量 Y 返回给算法模型系统。
S4:数据存储与通知
算法模型系统将接收到的订单量 Y 存储在 Redis 数据库中,并通知派单平台进行查询。
S5:场景判断(高 / 低并发)
派单平台查询数据后,根据阈值判断当前市场场景:
如果 Y > 2:判定为 “高并发” 场景(订单密集)。
如果 Y ≤ 2:判定为 “低并发” 场景(订单稀疏)。
S6 & S7:高并发场景播单策略
S6:在高并发场景下,平台优先考虑 第一轮抢单率,追求快速成交。每轮播单数量 A2 设定为 100 人。
S7:播单时,平台会实时计算司机的 抢单队列订单量 Z ,以判断其忙碌程度:
Z > 2:司机忙碌,本轮不予派单。
Z ≤ 2:司机空闲,可派单。
具体执行流程:
S71:如果剩余未播单司机数 ≤ A2 (100 人),则直接向所有这些司机发送抢单通知。
S72:如果剩余未播单司机数 > A2 (100 人),则按以下规则筛选:
将所有司机按 综合评价分 或派单分 排序后,平均分成 3 个部分。
从 每一部分 中随机 抽取 1/3 的播单数量(即约 33 名司机),确保样本的多样性和公平性。
规避重复:每轮播单不能选取已播过的司机。
忙碌司机处理:在选出的司机中,如果其 Z > 2(忙碌),则本轮跳过该司机。
名额补充:若因跳过忙碌司机导致可播单司机不足 A2,则用之前因忙碌被跳过的司机来补足剩余名额。
S8:低并发场景播单策略
在低并发场景下,每轮播单数量 A1 设定为 1000 人。
策略相对简单:将所有符合条件的司机按 综合评价分 或派单分 进行排序,直接向前 1000 名 司机发送抢单通知。
