58速运货物运输，滴滴快递网约车，司机端都是依照行进公里数收费的，所以“路程”的精确性，是这类事务的一个中心难题，“路程核算”计划演进，以及其间优化思维，是本文要评论的问题
一、直接调用地图API
这是最简单想到的办法，最省劲，但司机往往不是依照预订的路途行进的，很有或许由于堵车、路途关闭等改动路途，所以直接调用地图API，一次性核算出一个预估值，不太靠谱
优化计划
：依据实践路途核算路程
二、司机实时核算增量路程，服务端存储总路程
进程如下
：
（1）卡车方位不断的在改动，司机每隔一段时间（例如1s）记载一次GPS，即打点
（2）实时核算相邻两点的间隔，上报服务端
（3）服务端存储总路程
潜在问题
：
GPS
或许不精确，偶然会有噪点，一旦有噪点，相邻两点的间隔会很远，导致终究总路程或许比实践路程远
优化计划
：不能实时核算增量，而应该先打点，终究一致核算，这样才有时机去除噪点
三、打点上报服务端，服务端一致核算路程
进程如下
：
（1）卡车方位不断的在改动，司机每秒打一个点，上报服务端
（2）服务端将打点落地，记载数据库
（3）抵达目的地后，服务端关于一切点进行一致处理，一次性核算路程，能够去除噪点
潜在问题
：
假定每单均匀货运时长
1
小时，即每单要打
3600
个点，
58
速运每天
100w
订单，即总共要打
36
亿个点，每个点对应数据库一个写恳求，则
数据库的写压力大概在每秒
4w
次，扛不住
优化计划
：批量写是一种常见的下降数据库压力的计划
四、客户端实时打点，紧缩后批量上传
进程如下
：
（1）司机每秒在本地打点，每隔一段时间（例如20s），紧缩，上报服务端，服务端压力从4w下降到2k
（2）服务端解压，批量写入行列
（3）行列中的点，每隔一段时间（例如2s）再写入数据库
优化效果
：大大下降了数据库压力（由于存储量较大，实践优化的进程中，运用
Hbase
进行了优化存储）
其他问题
：数据库压力降下来了，但抵达目的地后，一个订单打的一切点核算路程，本钱较高，怎么削减核算量
优化计划
：去除无效点
五、打点过滤，进步功率
什么样的打点是无效点，需求去除呢？
（1）噪点准则：接连打点，偏移量较大的噪点，需求去除
（2）同点准则：相同方位的点能够去除，由于移动途径为0
（3）速度准则：行进速度超越合理规模的点，需求去除
（4）视点准则：理论上订单轨道是滑润有序的，假如视点重复折回，能够视为无效点
潜在问题
：假如司机有断网或许信号欠好，或许会漏点，导致核算出的总间隔小于实践间隔，给司机带来丢失
优化计划
：补点
六、事后补点，数据批改，核算路程
怎么进行补点，怎么进行数据批改呢？
（1）补点：车辆行进进程中，假如有中止路途，选用“地图途径规划”的方法补点
（2）批改：选用卡尔曼滤波算法，对轨道进行整形
（3）核算路程：依照点到点的间隔，进行累加
总结
“路程核算”的优化进程：
-
直接调用地图API
-
司机实时核算增量路程，服务端存储总路程
-
打点上报服务端，服务端一致核算路程
-
客户端实时打点，紧缩后批量上传
-
打点过滤，进步功率
-
事后补点，数据批改，核算路程
“路程核算”事务并不是一切公司都会涉及到，但其间的优化思路，许多仍是能够学习的：
-
单次与统筹
：客户端单次记载与核算是不靠谱的，应该由服务端来施行，归纳一切数据，去除噪点 -
单次与批量
：单次操作，压力较大，欠好紧缩；批量操作能大大下降压力，而且紧缩比高 -
全量与过滤
：全量核算本钱较高，过滤掉无效数据，能够下降核算量，进步精确性 -
弥补与批改
：关于少数短少的数据，能够猜测弥补，滑润批改
期望我们有收成。
