轉眼間2021年的五一假期已經過去瞭，經常被人詬病的12306購票系統今年毫無疑問的、又一次被網友吐槽瞭，原因自然就是又出現瞭加載速度過慢的問題：尤其是當網站開啟售票、搶票時，12306就會經常出現並發超荷的情況，這也不能怨12306的架構程序員，任何程序員面對一個每天點擊量高達1495億次、300多萬並發量的網站，估計都會頭疼不已尤其是五一長假期間，全國上下有幾億人在同時搶票，可以說12306承受瞭這個世界上能秒殺任何系統的QPS那麼其背後的服務端架構是什麼樣的呢？12306的進化史12306購票網站最早成立於2011年，上線的當天網站就迎來瞭十分巨大的訪問量，直接導致瞭網站的宕機，稍微的訂單和登錄人數增加就會導致服務器反應不及，車次信息和購票無法刷出。甚至有人登錄12306都無法進入，大大的“404錯誤”標識飄蕩在空空如也的網站上。往後數年的春運期間，12306都沒有抗住流量大考，甚至在2014年春運時徹底癱瘓。年年買不到票。用戶們這個年年吐槽12306。2015年，12306終於反應過來，開始與各類商業公司合作，比如將75%的餘票查詢業務切換到瞭阿裡雲上，火車票查詢業務占據瞭整個網站流量。合作後，提高瞭網站的負擔能力。2019年的春運，12306挺過瞭流量的高峰297億次的日訪問量。主要依靠的架構技術有下面幾種：1、大型高並發系統架構高並發的系統架構都會采用分佈式集群部署，服務上層有著層層負載均衡，並提供各種容災手段(雙火機房、節點容錯、服務器災備等)保證系統的高可用，流量也會根據不同的負載能力和配置策略均衡到不同的服務器上。下邊是一個簡單的示意圖:2、數據源先不說票少人多的問題，12306從早期一直到現在最大的問題就是遺留系統，也就是原來的火車站和售票點的那套這套系統部署在鐵路內部專網，而且票務數據也都留在各個鐵路局，所有最早的12306系統在查票和買票的時候，都會通過專用網閘和防火墻去又慢又不爽的各個鐵路局去查餘票和改餘票這樣子過防火墻在兩個網絡間查詢有多慢，大傢看最早的版本(2012年春節)就知道瞭，查詢一旦稍微高一點就掛，後來把查票單獨分離出來做瞭緩存處理，但是一直到現在的購票處理也都是要去鐵路內網的各個數據庫去改數據的。最後貌似做瞭預處理，把票放在一個票池子裡，提前分配，一少部分進入車站和網點，大部分到12306的網站，回流的退票也到票池子裡經過重新計算車次以後過段時間再重新放出來。就算這樣實際上也比較慢，因為數據是分散在不同的鐵路局（鐵路內網）的，這點鐵總也想把票都收到一起，到時候這個改進就是利益相關的扯皮瞭。3、分庫分表&讀寫分離實際上買票的消耗對於數據不算什麼，最可怕的實際上是查票，讀寫分離是一方面就是把查詢的庫從最早的Sybase換成Oracle，結果又是不行一直換成現在的內存庫，產品是VMware的GemFire，據說用瞭十幾個T的內存…這樣查票（讀，互聯網內存庫）和買票（寫，鐵路內網）就不在一個庫瞭，至於顯示有票但是買不到，那是因為兩個庫因為不在一個網絡定時同步的時間比較長而已。4、站點&前端&驗證說實在的就是把不同的應用分離，查票、買票、付款站點三個分開，這個是早就弄的。然後為瞭防止流量過大，把前端統統放到瞭CDN上，這也就是為啥如果你八一八12306的前端，會發現在首次載入的時候會把所有的頁面HTML、CSS和JS都帶進來，甚至包括全國的2500多個車站的車站列表和5000趟列車。還有據說是在Nginx端做瞭防止過快驗證的機器人判斷程序，你要是驗證碼輸入過快或者過頻繁就把你踢掉（不太清楚具體上線沒有或者上線效果是啥）5、雲端虛擬化把最消耗的查詢站點的一半以上放到瞭阿裡雲上6、分佈式中間件就是排隊嗎，這樣購票的動作就異步交給瞭消息隊列中間件，然後那個“有XX人排隊，你前邊有XX人”就是讀取消息隊列的位置和狀態（具體肯定比這個復雜），這個分佈式、異步、中間件、消息隊列的概念集成還是當年淘寶的技術團隊過來參與優化的時候留下的遺產。7、多機房&災備鐵總(中國鐵路總公司)和研究院，這個也不是啥新聞瞭，實際上是否是並行計算還是熱備還不清楚。12306現在基本上已經能夠支撐大數據量瞭，雖然直到現在仍有不少人吐槽12306的系統，但在程序員看來，12306的復雜程度已經超過瞭任何一款軟件。