58速运“里程计算”优化与演进

58速运货物运输,滴滴快递网约车,司机端都是按照行驶公里数收费的,所以“里程”的准确性,是这类业务的一个核心难题,“里程计算”方案演进,以及其中优化思想,是本文要讨论的问题

 

一、直接调用地图API

这是最容易想到的方法,最省事,但司机往往不是按照预定的路线行驶的,很有可能因为堵车、道路封闭等改变路线,所以直接调用地图API,一次性计算出一个预估值,不太靠谱

 

优化方案:根据实际路线计算里程

 

二、司机APP实时计算增量里程,服务端存储总里程

过程如下

1)货车位置不停的在改变,司机APP每隔一段时间(例如1s)记录一次GPS,即打点

2)实时计算相邻两点的距离,上报服务端

3)服务端存储总里程

 

潜在问题GPS可能不准确,偶尔会有噪点,一旦有噪点,相邻两点的距离会很远,导致最终总里程可能比实际里程远

 

优化方案:不能实时计算增量,而应该先打点,最终统一计算,这样才有机会去除噪点

 

三、打点上报服务端,服务端统一计算里程

过程如下

1)货车位置不停的在改变,司机APP每秒打一个点,上报服务端

2)服务端将打点落地,记录数据库

3)到达目的地后,服务端对于所有点进行统一处理,一次性计算里程,可以去除噪点

 

潜在问题假设每单平均货运时长1小时,即每单要打3600个点,58速运每天100w订单,即总共要打36亿个点,每个点对应数据库一个写请求,则数据库的写压力大概在每秒4w次,扛不住

 

优化方案批量写是一种常见的降低数据库压力的方案

 

四、客户端实时打点,压缩后批量上传

过程如下

1)司机APP每秒在本地打点,每隔一段时间(例如20s),压缩,上报服务端,服务端压力从4w降低到2k

2)服务端解压,批量写入队列

3)队列中的点,每隔一段时间(例如2s)再写入数据库

 

优化成果大大降低了数据库压力(由于存储量较大,实际优化的过程中,使用Hbase进行了优化存储)

 

其他问题:数据库压力降下来了,但到达目的地后,一个订单打的所有点计算里程,成本较高,如何减少计算量

 

优化方案:去除无效点

 

五、打点过滤,提高效率

什么样的打点是无效点,需要去除呢?

1噪点原则:连续打点,偏移量较大的噪点,需要去除

2同点原则:相同位置的点可以去除,因为移动路径为0

3速度原则:行驶速度超过合理范围的点,需要去除

4角度原则:理论上订单轨迹是平滑有序的,如果角度反复折回,可以视为无效点

 

潜在问题:如果司机APP有断网或者信号不好,可能会漏点,导致计算出的总距离小于实际距离,给司机带来损失

 

优化方案:补点

 

六、事后补点,数据修正,计算里程

如何进行补点,如何进行数据修正呢?

1补点:车辆行驶过程中,如果有中断路线,采用“地图路径规划”的方式补点

2修正:采用卡尔曼滤波算法,对轨迹进行整形

3计算里程:按照点到点的距离,进行累加

 

总结

“里程计算”的优化历程:

  • 直接调用地图API

  • 司机APP实时计算增量里程,服务端存储总里程

  • 打点上报服务端,服务端统一计算里程

  • 客户端实时打点,压缩后批量上传

  • 打点过滤,提高效率

  • 事后补点,数据修正,计算里程


“里程计算”业务并不是所有公司都会涉及到,但其中的优化思路,很多还是可以借鉴的:

  • 单次与统筹:客户端单次记录与计算是不靠谱的,应该由服务端来实施,综合所有数据,去除噪点

  • 单次与批量:单次操作,压力较大,不好压缩;批量操作能大大降低压力,并且压缩比高

  • 全量与过滤:全量计算成本较高,过滤掉无效数据,能够降低计算量,提高精确性

  • 补充与修正:对于少量缺少的数据,可以预测补充,平滑修正

希望大家有收获。

发表评论:

Copyright ft12.com All Rights Reserved.