一個O2O 打車APP 司機端自動匹配及接單系統的研究與實現

任健

（上海信息技術學校，上海200331）

1 本O2O 打車APP 的體系架構

面對“互聯網+”的大潮，各種商業模式不斷涌現，O2O 商業模式最貼近消費者的日常生活，是互聯網更好服務人們的體現[1]。作為對于O2O 模式的探索，“快的打車”和“滴滴打車”自上線后，用戶數便快速攀升[2]。現如今，網約車服務基本覆蓋了我國各大城市，青年人幾乎人手一個打車APP[3]。

本O2O 打車APP 采用客戶機/服務器（C/S）+瀏覽器/服務器（B/S）的體系架構，C/S 架構主要為手機APP 與服務器端的通信和功能實現，服務器端部署在阿里云上。B/S 架構主要通過瀏覽器呈現的方式為APP 運營方提供與服務器間的通信和功能實現。

圖1 APP 的體系架構

2 司機端自動匹配及接單系統的主要功能設計

自動匹配及接單系統包含訂單派發、尋找司機（車輛）、司機搶單、自動匹配、修改訂單等五個模塊。訂單派發模塊用于派發有效訂單；尋找司機（車輛）模塊用于尋找附近車輛，并向司機推送訂單信息；司機搶單模塊用于司機應答訂單；自動匹配模塊用于高效匹配司機；修改訂單模塊用于訂單信息修改等。

圖2 自動匹配及接單系統的主要模塊

對網約車訂單分配策略的研究，有助于減少乘客等待時間、提高司機收益、減少司機空載距離、提高資源利用率[4]。系統判定訂單數據有效后，派發訂單并尋找3 公里范圍內的司機（車輛），若尋找失敗則擴大范圍。系統將對符合條件的司機（車輛）進行排序，并推送訂單信息，隨后進入司機搶單流程，搶單成功則進入訂單執行環節，搶單失敗則進入訂單等待狀態。

圖3 司機端自動匹配及接單系統業務流程

2.1 司機搶單模塊

司機端搶單模塊要保證所有在線且空閑的司機實時獲得系統推送消息，繼而進行搶單操作，并最終根據司機搶單的先后順序判定搶單是否成功，是APP 功能模塊設計中的一個核心難點。本APP 采用基于Mina 的異步Socket 協議來突破這一難點，在采用異步方式進行請求響應、通過消息隊列分層、多進程處理的模式，服務器端的應用可以在處理響應的高峰期，不斷啟動處理進程來進行自身的服務擴展[5]。司機端與服務器端建立Socket鏈接；訂單信息判定為有效后，服務器將對符合條件的司機端進行廣播；司機搶單成功后，服務器調用回程線程推送搶單結果。

2.2 自動匹配模塊

如果當前沒有司機響應搶單，為確?？焖賾鹂蛻?，系統將自動查詢訂單附近的所有空閑車輛，并自動根據就近原則將訂單派送給接駕最快的車輛，司機可以根據實際情況選擇是否接單。

2.3 強制派單模塊

若自動匹配模塊選擇的車輛司機拒絕接單，APP 的后臺運營人員可以視情況，根據司機綜合評價排序，將該訂單強制派發給相關車輛及司機，強制派單后司機收到訂單并默認開始執行。

3 司機端自動匹配及接單系統相關功能的實現

作為一個O2O 打車APP 的核心功能，司機端搶單功能的公平性、有效性將直接影響司機和用戶的使用體驗，通過技術保障和邏輯控制，我們將為所有符合訂單搶單條件的司機提供搶單機會，結合自動匹配功能保證打車用戶的訂單能夠得到及時的響應和對接。

Android 系統司機端的部分核心代碼如下，APP 通過Flag 值判定搶單是否成功，搶單成功車輛及司機將前往用戶定位點接駕，搶單失敗或用戶取消則進入下一輪搶單流程：

根據搶單功能的技術需求，其核心為司機端與服務器端常連接狀態的保持，只有這樣，司機才能在第一時間接收到系統派發的用戶訂單，并保持實時響應。我們選用了ApacheMina 框架，它有助于開發高性能、高伸縮性的網絡應用程序，其核心為JavaNio 技術基于不同網絡傳輸協議的抽象、事件驅動的異步API，通過靈活地使用框架，我們可以保證司機端功能的正常運行，響應高效，回調迅速，對于消息推送、搶單及反饋等高并發業務環節具有顯著優勢。同時，不需要考慮與底層傳輸相關的具體細節，而只需要處理抽象的I/O 事件[6]。

圖4 建立連接、啟動服務、設置心跳參數的相關代碼

司機端使用Socket 協議與服務器端建立連接后，啟動相關服務并設置心跳參數，即通過持續、指定間隔的數據發送和反饋，確認司機端與服務器端的持續連接狀態。

以上代碼實現了對司機端狀態的持續監控，當司機端APP開啟、網絡正常、接單狀態下，通過獲取當前時間和心跳狀態進行判定，如心跳包發送失敗則重新連接。我們在使用線程鎖的同時，專設了一個監控線程，通過兩個線程的互相監控，確保心跳線程的持續運行。

綜上，本文基于一個O2O 打車APP 的體系架構、功能設計，對司機端自動匹配及接單系統中的司機搶單、自動匹配、強制派單等模塊進行了論述，對基于ApacheMina 框架實現司機端常連接的功能進行了研究，較為細致地闡述了核心技術思路及編碼邏輯。