一、網約車系統項目背景

Ptaxi網約車軟件開發客戶

二、網約車系統業務流程

網約車系統客戶端設計

考慮乘客獲取預估價格的查詢是否會有性能瓶頸，我的理解應該是調用地圖提供商接口，獲取公里數，再計算價格。只需考慮ecs能夠橫向擴容即可。

網約車系統司機端設計

搶單模式：

1.司機端搶單模式下，主動查詢符合條件的訂單列表，此處需要考慮列表查詢算法優化。壓力在數據庫端，避免全表掃描，可采用網格定義方式提高查詢效率，降低數據庫壓力。

2.獲取列表后，司機端需要點擊搶單，對于多個司機返回列表并排序在前的客戶訂單狀態，會存在熱更新，有且只有一個司機能夠對某個客戶訂單update并打上司機id。搶單時update司機id為搶單司機id where司機id=Null，并讀取update返回記錄條數，如果update返回記錄為0則說明搶單失敗，即司機id已被更新不為null。此處直接利用數據庫鎖即可，考慮到司機數量遠小于乘客數量，并且司機搶單并非定時秒殺模式，時間分散，因此數據庫鎖影響可以忽略。

派單模式：

后臺計算匹配的司機id，并向客戶端進行推送。此處僅需考慮對計算過程的效率以及性能壓力即可，同樣匹配邏輯是尋找最近距離司機，同樣通過網格編號查詢距離，通過子域id限定查詢范圍，提高查詢效率。

三、網約車系統架構設計

1.客戶端通過軟負載均衡SLB接入服務端。

2.服務端利用ESS彈性計算功能，支持在CPU超過一定閾值時，進行彈性擴容。

3.司機端服務于乘客端服務進行分離，以支持系統解耦，按需擴容。

4.司機端與乘客端服務器在首期只連接一個RDS數據庫，后續按需進行分布式數據庫擴容。

5.利用Redis存放網格id與網格子域的映射關系的映射關系，以保障快速查詢。

四、網約車系統核心算法

通過地圖網格算法的方式，降低經緯度計算壓力，通過網格子域的方式，減少查詢范圍，提高訂單匹配效率。網格算法：A1，B1，屬于同一子域（圖中不同顏色），子域ID為sub-zone，在同一子域中查詢匹配條件。

五、網約車系統性能評估

目標：通過性能評估，獲知系統支持容量，對后續擴容進行支持。

工具：Apache ab test

服務器配置：16c32g服務器上部署應用服務節點

測試條件：假設搶單時司機連續點擊次數平均為3次

測試內容：

程序只從數據庫讀取一條字段記錄做的select查詢處理的QPS壓測地址

http://www.fengzeys.com/api/test/qps

http://www.fengzeys.com/api/test/qps

程序做了事務處理的TPS壓測地址

http://www.fengzeys.com/api/test/tps

http://www.fengzeys.com/api/test/tps

測試結果分析：

1.HTTP性能明顯優于HTTPS性能，其中原因是HTTPS進行了通訊加密，應用程序還需承擔證書卸載的壓力，如果采用SLB進行證書卸載，HTTPS性能可以進一步提升。2.在HTTP通訊條件下，吞吐量QPS以及TPS均在并發為1000時出現拐點，因此該配置服務器最大支持的HTTP并發為1000，QPS最高為802，TPS最高為750。

3.在不采用SLB的情況下，吞吐量QPS以及TPS均在并發為500時出現拐點，因此該配置服務器最大支持的HTTPS并發為500，QPS最高113，TPS最高為130。

因此系統如需HTTP通訊支持吞吐量超過1000或HTTPS通訊支持吞吐量超過500時，則需要進行配置升級，通過橫向擴容進行支持，并考慮數據庫瓶頸情況。

六、推薦配置

根據性能評估結果，服務端配置至少兩臺16c32g以上進行負載均衡，單臺能夠達到700+QPS。后續按需進行橫向彈性擴容。拆分為4c8gECS則至少各需要4臺。

Ptaxi猿著專注出行軟件開發，提供打車軟件開發/出租車+電召系統開發/城際客運定制app開發/租車app開發/順風車軟件開發/代駕app開發；助力企業搭建網約車平臺，代辦或協助申請拿網絡預約出租汽車經營許可證！

更多資訊

95128電話叫車系統解決方案

Ptaxi猿著城際客運系統開發需求

Ptaxi猿著城際定制客運系統開發20220905升級日志

城際客運系統開發20220810升級日志

猿著打車軟件開發獲悉秦皇島市《網絡預約出租汽車運輸證》開始辦理

Ptaxi猿著打車系統軟件開發功能有哪些

Ptaxi網約車軟件開發獲悉三大造車新勢力，先后瞄準網約車市場

Ptaxi網約車系統開發轉載自動駕駛汽車運輸安全服務指南（試行）

Ptaxi網約車牌照申請獲悉東莞巡游出租車數量銳減，網約車數量持續增加