廣交天下好友：尼恩親手贈送廣受好評 、面試必備 、內力猛增的《 Java 高並發 三部曲 》，去了解詳情>>>
文章很長，而且持續更新，建議收藏起來，慢慢讀！ Java 高並發 發燒友社群：瘋狂創客圈（總入口） 奉上以下珍貴的學習資源：
推薦：入大廠 、做架構、大力提升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：設計模式面試題 （史上最全、持續更新、吐血推薦） |
| 17、分布式事務面試題 （史上最全、持續更新、吐血推薦） | 一致性協議 （史上最全） |
| 29、多線程面試題（史上最全） | 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）請求高峰時 數據庫負載過高
放票時（請求高峰時 下單請求、查詢請求過多， 導致訂單 / 電子客 票數據庫負載過高，造成數據庫連接數會被占滿。
數據庫的連接數是非常寶貴的系統資源，不可能無限增長，此時應用將無法再進行橫向擴容，業務將無法繼續發展。
訂單 / 電子客票數據庫負載過高時，對線下車站的換票業務產生影響。
（3）級聯雪崩：
AS 線程池的擁堵進一步造成 Web 對外服務線程的擁堵，影響頁面打開及業務邏輯處理，造 成頁面打開速度緩慢和超時錯誤。
（4）連接過多，性能下降
響應時間拉長之后，導致內外網安全平台上在活動及新建連接過多，性能下降，也導致 Web 訪問 AS 出錯。
（5）部分用戶不可用
為減輕網站壓力，降低查詢和下單的請求量， 網站被迫降級運行，限制在線的登錄用戶數量，造成部分用戶不能登錄網站。
結合系統監控數據，梳理上述主要問題的原因和關聯關系， 總結出主要問題：
是由於車票查詢以及訂單 / 電子客票業務分區處理能力不足，造成高峰期高並發訪問請求下響 應時間過長，加之各個業務分區未能很好進行隔離，導致系統由內至外產生“雪崩”效應，造成網站擁堵， 影響用戶的購票體驗。
優化后的架構圖
具體內容包括 ：
（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 以上，大幅提升了訂單 / 電子客票的查詢效率。
讀寫分離，避免了高並發、低延時要求的查詢操作影響交易處理 ；
（5）架構解耦 讀寫隔離
對訂票、取票操作進行了業務隔離，由不同的業務節點（售票節點和取票節點）承載網上售票和線下取票業務 ；
系統架構優化后的效果
優化架構后的系統在上線前壓力的測試中，極限交易能力為 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。
參考文獻：
