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實時計算增量里程，服務端存儲總里程
- 打點上報服務端，服務端統一計算里程
- 客戶端實時打點，壓縮后批量上傳
- 打點過濾，提高效率
- 事后補點，數據修正，計算里程
“里程計算”業務并不是所有公司都會涉及到，但其中的優化思路，很多還是可以借鑒的：
- 單次與統籌：客戶端單次記錄與計算是不靠譜的，應該由服務端來實施，綜合所有數據，去除噪點
- 單次與批量：單次操作，壓力較大，不好壓縮;批量操作能大大降低壓力，并且壓縮比高
- 全量與過濾：全量計算成本較高，過濾掉無效數據，能夠降低計算量，提高精確性
- 補充與修正：對于少量缺少的數據，可以預測補充，平滑修正
【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】
