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實時計算增量里程，服務端存儲總里程
• 打點上報服務端，服務端統一計算里程
• 客戶端實時打點，壓縮后批量上傳
• 打點過濾，提高效率
• 事后補點，數據修正，計算里程

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

• 單次與統籌：客戶端單次記錄與計算是不靠譜的，應該由服務端來實施，綜合所有數據，去除噪點
• 單次與批量：單次操作，壓力較大，不好壓縮;批量操作能大大降低壓力，并且壓縮比高
• 全量與過濾：全量計算成本較高，過濾掉無效數據，能夠降低計算量，提高精確性
• 補充與修正：對于少量缺少的數據，可以預測補充，平滑修正

【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】

戳這里，看該作者更多好文