當前位置：首頁 > 科技 > 軟件

聽說你會架構設計？來，弄一個公交&地鐵乘車系統

來源：責編：時間：2023-10-10 18:32:22 301觀看

導讀1. 引言1.1 上班通勤的日常“叮鈴鈴”，“叮鈴鈴”，早上七八點，你還在溫暖的被窩里和鬧鐘“斗智斗勇”。突然，你意識到已經快遲到了，于是像個閃電俠一樣沖進衛生間，速洗漱，急穿衣，左手抄起手機，右手拿起面包，邊穿衣邊啃早餐。這

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 狀態圖如下：

圖片

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

3）后臺系統的處理

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

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 算法來求兩點之間的最短路徑，具體步驟為：

步驟	已遍歷集合	未遍歷集合
1	選入A，此時最短路徑 A->A = 0，再以 A 為中間點，開始尋找下一個鄰近節點	{B、C、D、E、F}，其中與 A 相鄰的節點有 B 和 C，AB=6，AC=3。接下來，選取較短的路徑節點 C 開始遍歷
2	選取C，A->C=3，此時已遍歷集合為{A、C}，以 A 和 C 為中間點，開始尋找下一個鄰近節點	{B、D、E、F}，其中與 A、C 相鄰的節點有 B 和 D，AB=6，ACD=3+4=7。接下來，選取較短的路徑節點 B 開始遍歷
3	選取B，A->B=6，此時已遍歷集合為{A、C、B}，A 相鄰的節點已經遍歷結束，開始尋找和 B、C 相近的節點	{D、E、F}，其中與 B、C 相鄰的節點有 D，節點 D 在之前已經有了一個距離記錄（7），現在新的可選路徑是 ABD=6+5=11。顯然第一個路徑更短，于是將 D 的最近距離 7 加入到集合中
4	選取D，A->D=7，此時已遍歷集合為{A、C、B、D}，尋找 D 相鄰的節點	{E、F}，其中 DE=2，DF=3，選取最近路徑的節點 E 加入集合
5	選取 E，A->E=7+2=9，此時已遍歷集合為{A、C、B、D、E}，繼續尋找 D 和 E 相近的節點	{F}，其中 DF=3，DEF=2+5=7，于是F的最近距離為7+3=10.
6	選取F，A->F=10，此時遍歷集合為{A、C、B、D、E、F}	所有節點已遍歷結束，從 A 點出發，它們的最近距離分別為{A=0，C=3，B=6，D=7，E=9，F=10}

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

我們設定西經為負，南緯為負，所以地球上的經度范圍就是[-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") //轉成圖片保存    }}

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

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

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

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

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

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

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

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

4. 乘車系統的發展

4.1 其它設計

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

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

4.2 未來發展

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

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

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

本文鏈接：http://www.tebozhan.com/showinfo-26-12752-0.html聽說你會架構設計？來，弄一個公交&地鐵乘車系統

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com

上一篇：深入了解歸并排序：原理、性能分析與 Java 實現

下一篇： 500 多個純 CSS 實現的 Loading 效果，炫酷！

標簽：

熱門焦點

對標蘋果的靈動島華為帶來實況窗功能

繼蘋果的靈動島之后，華為也在今天正式推出了“實況窗”功能。據今天鴻蒙OS 4.0的現場演示顯示，華為的實況窗可以更高效的展現出實時通知，比如鎖屏上就能看到外賣、打車、銀行
7月安卓手機性價比榜：努比亞+紅魔兩款新機入榜

7月登場的新機有努比亞Z50S Pro和紅魔8S Pro，除了三星之外目前唯二的兩款搭載超頻版驍龍8Gen2處理器的產品，而且努比亞和紅魔也一貫有著不錯的性價比，所以在本次的性價比榜單
轎車從天而降電動車主被撞身亡超速搶道所致：現場視頻讓網友吵翻

近日，上海青浦區法院判決轎車從天而降電動車主被撞身亡案，轎車車主被判有期徒刑一年。案件顯示當時男子駕駛轎車在上海某路段行駛，前車忽然轉彎提速超車，
Java NIO內存映射文件：提高文件讀寫效率的優秀實踐！

Java的NIO庫提供了內存映射文件的支持，它可以將文件映射到內存中，從而可以更快地讀取和寫入文件數據。本文將對Java內存映射文件進行詳細的介紹和演示。內存映射文件概述內存
深度探索 Elasticsearch 8.X：function_score 參數解讀與實戰案例分析

在 Elasticsearch 中，function_score 可以讓我們在查詢的同時對搜索結果進行自定義評分。function_score 提供了一系列的參數和函數讓我們可以根據需求靈活地進行設置。近期
一個注解實現接口冪等，這樣才優雅！

場景碼猿慢病云管理系統中其實高并發的場景不是很多，沒有必要每個接口都去考慮并發高的場景，比如添加住院患者的這個接口，具體的業務代碼就不貼了，業務偽代碼如下：圖片上述代碼有
微軟邀請 Microsoft 365 商業用戶，測試視頻編輯器 Clipchamp

8 月 1 日消息，微軟近日宣布即將面向 Microsoft 365 商業用戶，開放 Clipchamp 應用，邀請用戶通過該應用來編輯視頻。微軟于 2021 年收購 Clipchamp，隨后開始逐步整合到 Microsof
華為Mate 60系列用上可變靈動島：正式版體驗將會更出色

這段時間以來，關于華為新旗艦的爆料日漸密集。據此前多方爆料，今年華為將開始恢復一年雙旗艦戰略，除上半年推出的P60系列外，往年下半年的Mate系列也將
首發天璣9200+ iQOO Neo8系列發布首銷售價2299元起

2023年5月23日晚，iQOO Neo8系列正式發布。其中，Neo系列首款Pro之作——iQOO Neo8 Pro強悍登場，限時售價3099元起；價位段最強性能手機iQOO Neo8同期上市

AVt天堂网手机版,亚洲va久久久噜噜噜久久4399,天天综合亚洲色在线精品,亚洲一级Av无码毛片久久精品

聽說你會架構設計？來，弄一個公交&地鐵乘車系統

1. 引言

1.1 上班通勤的日常

1.2 公交&地鐵乘車系統

2. 需求設計

2.1 功能需求

2.2 乘車系統的非功能需求

3. 概要設計

3.1 核心組件

3.2 乘車流程

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

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

3）后臺系統的處理

3. 詳細設計

3.1 數據庫設計

3.2 最短路線查詢

3.3 乘車二維碼管理

4. 乘車系統的發展

4.1 其它設計

4.2 未來發展

對標蘋果的靈動島華為帶來實況窗功能

7月安卓手機性價比榜：努比亞+紅魔兩款新機入榜

轎車從天而降電動車主被撞身亡超速搶道所致：現場視頻讓網友吵翻

Java NIO內存映射文件：提高文件讀寫效率的優秀實踐！

深度探索 Elasticsearch 8.X：function_score 參數解讀與實戰案例分析

一個注解實現接口冪等，這樣才優雅！

微軟邀請 Microsoft 365 商業用戶，測試視頻編輯器 Clipchamp

華為Mate 60系列用上可變靈動島：正式版體驗將會更出色

首發天璣9200+ iQOO Neo8系列發布首銷售價2299元起

最新推薦

猜你喜歡

熱門推薦

相關資訊

聽說你會架構設計？來，弄一個公交&amp;地鐵乘車系統

1. 引言

1.1 上班通勤的日常

1.2 公交&地鐵乘車系統

2. 需求設計

2.1 功能需求

2.2 乘車系統的非功能需求

3. 概要設計

3.1 核心組件

3.2 乘車流程

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

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

3）后臺系統的處理

3. 詳細設計

3.1 數據庫設計

3.2 最短路線查詢

3.3 乘車二維碼管理

4. 乘車系統的發展

4.1 其它設計

4.2 未來發展

最新推薦

猜你喜歡

熱門推薦

相關資訊

聽說你會架構設計？來，弄一個公交&地鐵乘車系統