架構案例：12306搶票億級流量架構演進（圖解+秒懂+史上最全）

文章很長，並且持續更新，建議收藏起來，慢慢讀！ Java 高併發 發燒友社羣：瘋狂創客圈（總入口） 奉上如下珍貴的學習資源：

• 免費贈送 經典圖書 ： 極致經典 + 社羣大片好評 《 Java 高併發 三部曲 》 面試必備 + 大廠必備 + 漲薪必備
• 免費贈送 經典圖書 ： 《Netty Zookeeper Redis 高併發實戰》 面試必備 + 大廠必備 +漲薪必備 （加尼恩領取）
• 免費贈送 經典圖書 ： 《SpringCloud、Nginx高併發核心編程》 面試必備 + 大廠必備 + 漲薪必備 （加尼恩領取）
• 免費贈送 資源寶庫： Java 必備 百度網盤資源大合集 價值>10000元 （加尼恩領取）

---

推薦：入大廠 、作架構、大力提高Java 內功 的 精彩博文

入大廠 、作架構、大力提高Java 內功 必備的精彩博文	2021 秋招漲薪1W + 必備的精彩博文
1：Redis 分佈式鎖 （圖解-秒懂-史上最全）	2：Zookeeper 分佈式鎖 （圖解-秒懂-史上最全）
3: Redis與MySQL雙寫一致性如何保證？ （面試必備）	4: 面試必備：秒殺超賣 解決方案 （史上最全）
5:面試必備之：Reactor模式	6: 10分鐘看懂， Java NIO 底層原理
7:TCP/IP（圖解+秒懂+史上最全）	8：Feign原理 （圖解）
9:DNS圖解（秒懂 + 史上最全 + 高薪必備）	10：CDN圖解（秒懂 + 史上最全 + 高薪必備）
11: 分佈式事務（ 圖解 + 史上最全 + 吐血推薦 ）

---

Java 面試題 30個專題 , 史上最全 , 面試必刷	阿里、京東、美團... 隨意挑、橫着走！！！
1： JVM面試題（史上最強、持續更新、吐血推薦）	2：Java基礎面試題（史上最全、持續更新、吐血推薦
3：架構設計面試題 （史上最全、持續更新、吐血推薦）	4：設計模式面試題 （史上最全、持續更新、吐血推薦）
1七、分佈式事務面試題 （史上最全、持續更新、吐血推薦）	一致性協議 （史上最全）
2九、多線程面試題（史上最全）	30、HR面經，過五關斬六將後，當心陰溝翻船！
9.網絡協議面試題（史上最全、持續更新、吐血推薦）	更多專題， 請參見【 瘋狂創客圈 高併發 總目錄 】

---

SpringCloud 精彩博文
nacos 實戰（史上最全）	sentinel （史上最全+入門教程）
SpringCloud gateway （史上最全）	更多專題， 請參見【 瘋狂創客圈 高併發 總目錄 】

---

第一代架構：雙機熱備模式

2011 年 6 月 12 日，系統投入試運行，發售京津城際 列車車票；2011 年 9 月 30 日，發售全路動車組車票；

2011 年末，發售全路列車車票，互聯網正式成爲鐵 路新的售票渠道。

互聯網售票系統設計了緩存服務、用戶管理、車票查詢、訂單及電子客票處理 等多個相對獨立的業務分區，以及三級網絡安全域， 分別是外網、內網和客票網，系統的體系架構如圖 所示：

數據庫的維度：

用戶管理、車票查詢採用了傳統的關係型數據庫。

其中車票查詢業務部署了多套負載均衡工做模式的數據庫， 訂單/ 電子客票處理業務採用了雙機熱備模式的數據庫，上述數據庫均運行在小型機平臺上。

外網的車次、 餘票等緩存服務採用了基於內存計算的 NoSQL 數據 庫，運行在 X86 平臺上。

第一代架構的性能：

上線前的壓力測試，一筆 流程包含用戶登陸、車票查詢、下單及支付等業務操做，系統極限交易能力爲 34 張 /s，按按高峯期 10 h計算，售票量可達到 120 萬張 / 天的設計能力。

第一代網絡架構：

第二代架構：緩存提速+隊列削峯+分庫分表+讀寫分離

主要問題 ：

2012 年春運期間，因爲訪問量超出設計預期， 12306 網站在高峯期出現了一系列問題：

• 頁面打開緩慢、

• 查詢和下 單報錯

• 後臺系統過載

• 用戶體驗不佳

根因分析 ：

（1）請求高峯（相似於秒殺）響應遲緩

放票時 高併發的下單集中在一塊兒，造成請求高峯（相似於秒殺），請求導致訂單 / 電子客 票數據庫負載太高，引發交易響應時間過長，形成 AS 以及 inetis 的交易線程池擁堵。

下單長時間不響應，同一次購買，用戶會反覆重試，從而加重擁堵。 因爲響應時間過程，用戶進而反覆重試，一次操做變成屢次，操做此時倍數增加，進一步 形成 AS（Application Server）的查詢線程池擁堵, 致使響應時間進一步拉長

假如是tomcat ，設計了340條線程，1000人買票，數據庫操做每秒34個訂單，線程池就滿了。

請求還須要在等待隊列中排隊。

最大工做線程數，默認200。
server.tomcat.max-threads=200

最大鏈接數默認是10000
server.tomcat.max-connections=1000000

等待隊列長度，默認100。
server.tomcat.accept-count=1000

最小工做空閒線程數，默認10。
server.tomcat.min-spare-threads=100

（2）級聯雪崩：

AS 線程池的擁堵進一步形成 Web 對外服務線程的擁堵，影響頁面打開及業務邏輯處理，造 成頁面打開速度緩慢和超時錯誤。

（3）鏈接過多，性能降低

內外網安全平臺上在活動及新建鏈接過多，性能降低，也致使 Web 訪問 AS 出錯。

（5）訂單 / 電子客票數據庫負載太高時，對線下車站的換票業務產生影響。

（6）爲減輕網站壓力，下降查詢和下單的請求量， 網站被迫降級運行，限制在線的登陸用戶數量，形成部分用戶不能登陸網站。

結合系統監控數據，梳理上述主要問題的緣由和關聯關係， 總結出主要問題：

是因爲車票查詢以及訂單 / 電子客票業務分區處理能力不足，形成高峯期高併發訪問請求下響 應時間過長，加之各個業務分區未能很好進行隔離，致使系統由內至外產生「雪崩」效應，形成網站擁堵， 影響用戶的購票體驗。

優化後的架構圖

具體內容包括 ：

（1）全面使用緩存

使用內存計算 NoSQL 數據庫取代傳統數據 庫，大幅提高車票併發查詢能力，車票查詢的 TPS/QPS（Transaction/Query per Second）由不足 1000 次 /s 提高至超過 20000 次 /s，RT（Response Time）由原來的 1 s 縮減至 10 ms，使用戶能夠快速 獲取到車次及餘票狀況。

（2）隊列削峯：

構建交易處理排隊系統，系統先經過隊列 接收用戶的下單請求，再根據後端處理能力異步地 處理隊列中的下單請求。

隊列的下單請求接收能力超過 10 萬筆 / 秒，用戶能夠在售票高峯期迅速完成 下單操做，等候系統依次處理，等候過程當中能夠查詢排隊狀態（等候處理的時間）。

隨後的下單操做（訂票請·求）直接由排隊系統壓入隊列處理，不一樣的車次 / 日期進入不一樣的隊列， 訂票請求再也不

直接面對內網 核心交 易系統。

具體實現時，考慮到車票查詢結果有緩存延 時，在訂票請求進入隊列前，還將實時查詢車次餘票， 確有餘票且當前排隊人數不超過餘票數量時才最終容許訂票請求進入隊列。

排隊系統收到請求後，採用動態流量控制策略，即根據位於客票網各個鐵路 局客票中心的席位處理以及訂單 / 電子客票集羣處理 的響應時間，向 AS 提交用戶的訂票請求，處理響應 時間放慢，則提交速度放慢，反之則提升訂票請求 的提交速度。

（3）分庫分表:

對訂單 / 電子客票進行分節點分庫分表改造， 將原有的 1 個節點 1 個庫 1 張表物理拆分爲 3 個節點 30 個庫 30 張表，線上相關操做按用戶名 HASH 的方式被分散到各個節點和庫表中，有效提高了核 心交易的處理能力並具有繼續橫向擴充能力，使用 戶在隊列中的訂票請求能夠獲得更快的響應和處理。

（4）讀寫分離：

對訂單 / 電子客票生成和查詢進行了讀寫分離：

使用內存計算 NoSQL 數據庫集中存 儲訂單 / 電子客票，提供以 Key-Value 爲主的查詢服 務，訂單查詢的 TPS 由 200 次 /s 左右提高至 5 000 次 /s 以上，大幅提高了訂單 / 電子客票的查詢效率。

讀寫分離，避免了高併發、低延時要求的查詢操做影響交易處理 ；

對訂票、取票操做進行了業務分離，由不一樣的業務節點（售票節點和取票節點）承載網上售票和線下取票業務 ；

系統架構優化後的效果

優化架構後的系統在上線前壓力的測試中，極限交易能力爲 300 張 /s，可 以知足日售票量 500 萬的業務需求。

2013 年春運，優化架構後的 12306 網站最高日 售票量達到 364 萬，佔全路售票量的 40%，售票量 爲 2012 年春運最高峯（119 萬）的 3 倍多

第三代架構：異地雙活+公私結合

2013 年十一黃金週，12306 互聯網售票量達到 了 460 萬（到達系統瓶頸），再次接近系統處理的上限，且高峯期外 網入口帶寬緊張，已不能知足互聯網售票量進一步 提高的須要。此外，做爲鐵路售票的主要渠道，互 聯網售票系統單中心運行模式已不能知足業務安全 性和可靠性的需求。

系統架構優化

爲此，自 2013 年末起啓動了 12306 網站的第 2 輪架構優化，優化目標旨在提升系 統的安全可靠性，以及在高峯期具有處理容量的彈 性擴充能力，具體內容包括:

（1）加緩存：將用戶登陸及經常使用聯繫人查詢等業務遷移 至內存數據庫中，提升了相關業務的處理性能和可 靠性。

（2）IDC雙活：構建中國鐵道科學研究院第 2 生產中心，與既有的中國鐵路總公司第 1 生產中心間實現雙活， 提高網站的安全性和可靠性，並將訂單 / 電子客票集 羣的處理能力提升 1 倍。

（3）公私結合：在公有云上部署車票查詢服務，經過策略 配置可隨時將車票查詢流量分流至公用雲，以緩解 在售票高峯期網站的處理資源和帶寬壓力。

在雙活架構的建設過程當中，咱們將訂單 / 電子客 票集羣徹底遷移至 X86 虛擬化平臺，並擴充至 10 組 節點，100 個庫，100 張表。

上線前的壓力測試驗證了 系統能夠知足 1 000 萬張 / 天的設計售票能力，在 2015 年春運高峯時段，實際售票速度超過了 1 000 張 /s（約 合 360 萬張 /h）。

第 1 生產中心、第 2 生產中心間訂 單 / 電子客票集羣具有熱切換能力，顯著提升了系統 的故障隔離能力和系統的安全及可靠性。

公有云在 2015 年春運期間最高分流了 75% 的查詢請求，網站 對外車票查詢服務能力增長了 3 倍。

12306 網站在 2015 年春運高峯日處理了超過 180 億 次車票查詢服務，平均 TPS 超過 30 萬次 /s。

參考文獻：