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

发布时间：2025-11-05 02:36:18 来源：创站工坊 作者：IT科技类资讯

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)计算里程：按照点到点的距离，进行累加

总结

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

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

【本文为专栏作者“58沈剑”原创稿件，转载请联系原作者】

戳这里，看该作者更多好文

相关文章