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實時計算增量里程，服務端存儲總里程

• 打點上報服務端，服務端統一計算里程

• 客戶端實時打點，壓縮后批量上傳

• 打點過濾，提高效率

• 事后補點，數據修正，計算里程

“里程計算”業務并不是所有公司都會涉及到，但其中的優化思路，很多還是可以借鑒的：

• 單次與統籌：客戶端單次記錄與計算是不靠譜的，應該由服務端來實施，綜合所有數據，去除噪點

• 單次與批量：單次操作，壓力較大，不好壓縮；批量操作能大大降低壓力，并且壓縮比高

• 全量與過濾：全量計算成本較高，過濾掉無效數據，能夠降低計算量，提高精確性

• 補充與修正：對于少量缺少的數據，可以預測補充，平滑修正

希望大家有收獲。