1. 引言

1.1 上班通勤的日常

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

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

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

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

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

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

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

1.2 公交&地鐵乘車系統(tǒng)

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

那這個便捷的公交或地鐵乘車系統(tǒng)是如何設(shè)計的呢？它背后的技術(shù)和架構(gòu)是怎樣支撐著你我每天的通勤生活呢？

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

在這個文章中，小?將帶你走進乘車系統(tǒng)的世界，一探究竟，看看它是如何在短短幾年內(nèi)從科幻電影中走出來，成為我們?nèi)粘Ｉ畈豢苫蛉钡囊徊糠帧?/p>

2. 需求設(shè)計

2.1 功能需求

圖片

• 用戶注冊和登錄： 用戶可以通過手機應(yīng)用或小程序注冊賬號，并使用賬號登錄系統(tǒng)。
• 路線查詢： 用戶可以查詢地鐵的線路和站點信息，包括發(fā)車時間、車票價格等。
• 獲取乘車二維碼： 系統(tǒng)根據(jù)用戶的信息生成乘車二維碼。
• 獲取地鐵實時位置： 用戶可以查詢地鐵的實時位置，并查看地鐵離當(dāng)前站臺還有多久到達。
• 乘車掃描和自動支付： 用戶在入站和出站時通過掃描二維碼來完成乘車，系統(tǒng)根據(jù)乘車?yán)锍套詣佑嬎阗M用并進行支付。
• 交易記錄查詢： 用戶可以查詢自己的交易歷史記錄，包括乘車時間、金額、線路等信息。

2.2 乘車系統(tǒng)的非功能需求

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

所以，設(shè)計一個熱點數(shù)據(jù)分布非均勻、人群分布非均勻的乘車系統(tǒng)時，需要考慮如下幾點：

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

3. 概要設(shè)計

3.1 核心組件

圖片

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

3.2 乘車流程

1）用戶手機與后臺系統(tǒng)的交互

交互時序圖如下：

圖片

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

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

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

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

交互 UML 狀態(tài)圖如下：

圖片

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

3）后臺系統(tǒng)的處理

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

3. 詳細(xì)設(shè)計

3.1 數(shù)據(jù)庫設(shè)計

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

以上是一些在公交車&地鐵乘車系統(tǒng)中需要設(shè)計的數(shù)據(jù)庫表及其字段的基本信息，后續(xù)可根據(jù)具體需求和系統(tǒng)規(guī)模，還可以進一步優(yōu)化表結(jié)構(gòu)和字段設(shè)計，以滿足性能和擴展性要求。

詳細(xì)設(shè)計除了要設(shè)計出表結(jié)構(gòu)以外，我們還針對兩個核心問題進行討論：

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

3.2 最短路線查詢

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

圖片

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

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

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

圖片

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

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

一旦獲得了起始地點的經(jīng)緯度，系統(tǒng)就可以根據(jù)附近的站點信息，調(diào)用路線管理系統(tǒng)來查找最佳的公交或地鐵路線。

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

3.3 乘車二維碼管理

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

圖片

二維碼的生成非常簡單，拿 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") //轉(zhuǎn)成圖片保存
    }
}

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

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

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

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

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

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

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

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

4. 乘車系統(tǒng)的發(fā)展

4.1 其它設(shè)計

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

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

4.2 未來發(fā)展

公交車/地鐵乘車系統(tǒng)的未來發(fā)展可以包括以下方向：

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

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