1. 引言

1.1 上班通勤的日常

“叮鈴鈴”，“叮鈴鈴”，早上七八點，你還在溫暖的被窩里和鬧鐘“斗智斗勇”。

突然，你意識到已經快遲到了，于是像個閃電俠一樣沖進衛生間，速洗漱，急穿衣，左手抄起手機，右手拿起面包，邊穿衣邊啃早餐。

這個時候，通勤的老難題又擺在了你面前：要不要吃完這口面包、刷牙和洗臉，還是先沖出門趕車？

好不容易做出了一個艱難的決定——放下面包，快步沖出門。你拿出手機，點開了熟悉的地鐵乘車 App 或公交地鐵乘車碼小程序。

然后，一張二維碼在屏幕上亮了起來，這可是你每天通勤的“敲門磚”。

你快步走到地鐵站，將手機二維碼掃描在閘機上，"嗖"的一聲，閘機打開，你輕松通過，不再需要排隊買票，不再被早高峰的擁擠鬧心。

你走進地鐵車廂，擠到了一個角落，拿出手機，開始計劃一天的工作。

1.2 公交&地鐵乘車系統

正如上文所說，人們只需要一臺手機，一個二維碼就可以完成上班通勤的所有事項。

那這個便捷的公交或地鐵乘車系統是如何設計的呢？它背后的技術和架構是怎樣支撐著你我每天的通勤生活呢？

今天讓我們一起揭開這個現代都市打工人通勤小能手的面紗，深入探討乘車系統的設計與實現。

在這個文章中，小?將帶你走進乘車系統的世界，一探究竟，看看它是如何在短短幾年內從科幻電影中走出來，成為我們日常生活不可或缺的一部分。

2. 需求設計

2.1 功能需求

圖片

• 用戶注冊和登錄： 用戶可以通過手機應用或小程序注冊賬號，并使用賬號登錄系統。
• 路線查詢： 用戶可以查詢地鐵的線路和站點信息，包括發車時間、車票價格等。
• 獲取乘車二維碼： 系統根據用戶的信息生成乘車二維碼。
• 獲取地鐵實時位置： 用戶可以查詢地鐵的實時位置，并查看地鐵離當前站臺還有多久到達。
• 乘車掃描和自動支付： 用戶在入站和出站時通過掃描二維碼來完成乘車，系統根據乘車里程自動計算費用并進行支付。
• 交易記錄查詢： 用戶可以查詢自己的交易歷史記錄，包括乘車時間、金額、線路等信息。

2.2 乘車系統的非功能需求

乘車系統的用戶量非常大，據《中國主要城市通勤檢測報告-2023》數據顯示，一線城市每天乘公交&地鐵上班的的人數普遍超過千萬，平均通勤時間在 45-60 分鐘，并集中在早高峰和晚高峰時段。

所以，設計一個熱點數據分布非均勻、人群分布非均勻的乘車系統時，需要考慮如下幾點：

• 用戶分布不均勻，一線城市的乘車系統用戶，超出普通城市幾個數量級。
• 時間分布不均勻，乘車系統的設計初衷是方便上下班通勤，所以早晚高峰的用戶數會高出其它時間段幾個數量級。
• 高并發： 考慮到公交車/地鐵系統可能同時有大量的用戶在高峰時段使用，系統需要具備高并發處理能力。
• 高性能： 為了提供快速的查詢和支付服務，系統需要具備高性能，響應時間應盡可能短。
• 可擴展性： 隨著用戶數量的增加，系統應該容易擴展，以滿足未來的需求。
• 可用性： 系統需要保證24/7的可用性，隨時提供服務。
• 安全和隱私保護： 系統需要確保用戶數據的安全和隱私，包括支付信息和個人信息的保護。

3. 概要設計

3.1 核心組件

圖片

• 前端應用： 開發手機 App 和小程序，提供用戶注冊、登錄、查詢等功能。
• 后端服務： 設計后端服務，包括用戶管理、路線查詢、二維碼管理、訂單處理、支付系統等。
• 數據庫： 使用關系型數據庫 MySQL 集群存儲用戶信息、路線信息、交易記錄等數據。
• 推送系統： 將乘車后的支付結果，通過在線和離線兩種方式推送給用戶手機上。
• 負載均衡和消息隊列： 考慮使用負載均衡和消息隊列技術來提高系統性能。

3.2 乘車流程

1）用戶手機與后臺系統的交互

交互時序圖如下：

圖片

1. 用戶注冊和登錄： 用戶首先需要在手機應用上注冊并登錄系統，提供個人信息，包括用戶名、手機號碼、支付方式等。

2. 查詢乘車信息： 用戶可以使用手機應用查詢公交車/地鐵的路線和票價信息，用戶可以根據自己的出行需求選擇合適的線路。

3. 生成乘車二維碼： 用戶登錄后，系統會生成一個用于乘車的二維碼，這個二維碼可以在用戶手機上隨時查看。這個二維碼是城市公交系統的通用乘車二維碼，同時該碼關聯到用戶的賬戶和付款方式，用戶可以隨時使用它乘坐任何一輛公交車或地鐵。

2）用戶手機與公交車的交互

交互 UML 狀態圖如下：

圖片

1. 用戶進站掃碼： 當用戶進入地鐵站時，他們將手機上的乘車碼掃描在進站設備上。這個設備將掃描到的乘車碼發送給后臺系統。
2. 進站數據處理： 后臺系統接收到進站信息后，會驗證乘車碼的有效性，檢查用戶是否有進站記錄，并記錄下進站的時間和地點。
3. 用戶出站掃碼： 用戶在乘車結束后，將手機上的乘車碼掃描在出站設備上。
4. 出站數據處理： 后臺系統接收到出站信息后，會驗證乘車碼的有效性，檢查用戶是否有對應的進站記錄，并記錄下出站的時間和地點。

3）后臺系統的處理

1. 乘車費用計算： 基于用戶的進站和出站地點以及乘車規則，后臺系統計算乘車費用。這個費用可以根據不同的城市和運營商有所不同。
2. 費用記錄和扣款： 系統記錄下乘車費用，并從用戶的付款方式（例如，支付寶或微信錢包）中扣除費用。
3. 乘車記錄存儲： 所有的乘車記錄，包括進站、出站、費用等信息，被存儲在乘車記錄表中，以便用戶查看和服務提供商進行結算。
4. 通知用戶： 如果有需要，系統可以向用戶發送通知，告知他們的乘車費用已被扣除。
5. 數據庫交互： 在整個過程中，系統需要與數據庫交互來存儲和檢索用戶信息、乘車記錄、費用信息等數據。

3. 詳細設計

3.1 數據庫設計

• 用戶信息表（User），包括用戶ID、手機號、密碼、支付方式、創建時間等。
• 二維碼表 (QRCode)，包括二維碼ID、用戶ID、城市ID、生成時間、有效期及二維碼數據等。
• 車輛&地鐵車次表 (Vehicle)，包括車輛ID、車牌或地鐵列車號、車型（公交、地鐵）、掃描設備序列號等。
• 乘車記錄表 (TripRecord)，包括記錄ID、用戶ID、車輛ID、上下車時間、起止站點等。
• 支付記錄表 (PaymentRecord)，包括支付ID、乘車記錄ID、交易時間、交易金額、支付方式、支付狀態等。

以上是一些在公交車&地鐵乘車系統中需要設計的數據庫表及其字段的基本信息，后續可根據具體需求和系統規模，還可以進一步優化表結構和字段設計，以滿足性能和擴展性要求。

詳細設計除了要設計出表結構以外，我們還針對兩個核心問題進行討論：

• 最短路線查詢
• 乘車二維碼管理

3.2 最短路線查詢

根據交通部門給的公交&地鐵路線，我們可以繪制如下站點圖：

圖片

假設圖中的站點有 A-F，涉及到的交通工具有地鐵 1 號線和 2 路公交，用戶的起點和終點分別為 A、F 點。我們可以使用 Dijkstra 算法來求兩點之間的最短路徑，具體步驟為：

在用戶查詢路線之前，交通部門會把公交 & 地鐵的站點經緯度信息輸入到路線管理系統，并根據二維的空間經緯度編碼存儲對應的站點信息。

我們設定西經為負，南緯為負，所以地球上的經度范圍就是[-180， 180]，緯度范圍就是[-90，90]。如果以本初子午線、赤道為界，地球可以分成 4 個部分。

圖片

根據這個原理，我們可以先將二維的空間經緯度編碼成一個字符串，來唯一標識用戶或站點的位置信息。再通過 Redis 的 GeoHash 算法，來獲取用戶出發點附近的所有站點信息。

GeoHash 算法的原理是將一個位置的經緯度換算成地址編碼字符串，表示在某個矩形區域，通過這個算法可以快速找到同一個區域的所有站點。

一旦獲得了起始地點的經緯度，系統就可以根據附近的站點信息，調用路線管理系統來查找最佳的公交或地鐵路線。

一旦用戶選擇了一條路線，導航引擎啟動并提供實時導航指引。導航引擎可能會使用地圖數據和 GPS 定位來指導用戶前往起止站點。

3.3 乘車二維碼管理

乘車碼是通過 QR 碼（Quick Response Code）技術生成的，它比傳統的 Bar Code 條形碼能存更多的信息，也能表示更多的數據類型，如圖所示：

圖片

二維碼的生成非常簡單，拿 Go 語言來舉例，只需引入一個三方庫：

import "github.com/skip2/go-qrcode"

func main() {
    qr,err:=qrcode.New("https://mp.weixin.qq.com",qrcode.Medium)
if err != nil {
    log.Fatal(err)
} else {
    qr.BackgroundColor = color.RGBA{50,205,50,255} //定義背景色
    qr.ForegroundColor = color.White //定義前景色
    qr.WriteFile(256,"./wechatgzh_qrcode.png") //轉成圖片保存
    }
}

以下是該功能用戶和系統之間的交互、二維碼信息存儲、以及高并發請求處理的詳細說明：

1. 用戶與系統交互： 用戶首先在手機 App 上登錄，系統會驗證用戶的身份和付款方式。一旦驗證成功，系統根據用戶的身份信息和付款方式，動態生成一個 QR 碼，這個 QR 碼包含了用戶的標識信息和相關的乘車參數。
2. 二維碼信息存儲： 生成的二維碼信息需要在后臺進行存儲和關聯。通常，這些信息會存儲在一個專門的數據庫表中，該表包含以下字段：

• 二維碼ID：主鍵ID，唯一標識一個二維碼。
• 用戶ID：與乘車碼關聯的用戶唯一標識。
• 二維碼數據：QR碼的內容，包括用戶信息和乘車參數。
• 生成時間：二維碼生成的時間戳，用于后續的驗證和管理。
• 有效期限：二維碼的有效期，通常會設置一個時間限制，以保證安全性。

3. 高并發請求處理： 在高并發情況下，大量的用戶會同時生成和掃描二維碼，因此需要一些策略來處理這些請求：

• 負載均衡： 后臺系統可以采用負載均衡技術，將請求分散到多個服務器上，以分擔服務器的負載。
• 緩存優化： 二維碼的生成是相對耗時的操作，可以采用 Redis 來緩存已生成的二維碼，避免重復生成。
• 限制頻率： 為了防止濫用，可以限制每個用戶生成二維碼的頻率，例如，每分鐘只允許生成 5  次，這可以通過限流的方式來實現。

總之，通過 QR 碼技術生成乘車碼，后臺系統需要具備高并發處理的能力，包括負載均衡、緩存和頻率限制等策略，以確保用戶能夠快速獲得有效的乘車二維碼。

同時，二維碼信息需要被安全地存儲和管理，比如：加密存儲以保護用戶的隱私和付款信息。

不清楚如何限流的，可以看我之前的這篇文章：若我問到高可用，閣下又該如何應對呢？

4. 乘車系統的發展

4.1 其它設計

除此之外，公交車或地鐵的定位和到站時間計算可能還涉及定位設備、GPS 系統、NoSQL 數據庫、用戶 TCP 連接管理系統等核心組件，并通過實時數據采集、位置處理、到站時間計算和信息推送等流程來為用戶提供準確的乘車信息。

同時，自動支付也是為了方便用戶的重要功能，可以通過與第三方支付平臺的集成來實現。

4.2 未來發展

公交車/地鐵乘車系統的未來發展可以包括以下方向：

• 智能化乘車： 引入智能設備，如人臉自動識別乘客、人臉扣款等。
• 大數據分析： 利用大數據技術分析乘車數據，提供更好的服務。

在設計和發展過程中，也要不斷考慮用戶體驗、性能和安全，確保系統能夠滿足不斷增長的需求。