注：本文首發於CSDN，轉載請標明出處。
【編者按】12306網站曾被認爲是“全球最忙碌的網站”，在應對高併發訪問處理方面，曾備受網民詬病。 2015年鐵路客票春運購票高峯期已過，並且12306網站今年沒“癱瘓”，也順利過關。因此記者在第一時間聯繫到一位對12306改造非常關注的技術架構師，他從技術的角度，用科學論證的方式，指出原因所在，並根據他的經驗進一步說明12306是如何實現高流量高併發的關鍵技術，與大家共享。以下爲正文：
預告：2015年3月中旬左右，技術揭祕12306改造（二）：如何實現 12306 混合雲的架構；4月中旬：技術揭祕12306改造（三）：如何將傳統技術架構遷移到Gemfire的雲平臺……（注：選題爲初步計劃，中途會有所更改，敬請關注。）
前言：
12306互聯網售票系統在2011年下半年開始上線使用，但在2012年春運期間引發無數的爭議。在2012年春運後，12306項目承接單位與多家IT公司聯繫，經過多次論證和POC 測試， 最終引入分佈式內存運算數據管理雲平臺 - Pivotal Gemfire做試點，用以提高12306系統性能，解決“高流量和高併發“的難題。
高流量高併發是指某特定時間段的海量請求，根據過去的經驗法則，高併發是指訪問流量是平常流量的 3-5倍；但由於互聯網和移動設備apps的普遍化，電商網站的促銷模式“11.11“，或是廠商的“飢餓營銷“，都會衍生“秒殺“現象。所以過去的經驗法則用到12306春運售票系統，往往是遠遠低於實際的的流量。例如，12306平常一天的PV（page views）值大約是在 2500萬到 3000萬左右， 在2015年春運高峯日的PV值是297億，流量增加1000倍，這樣海量的請求，假如不能在短時間內動態調整網絡帶寬或增加服務器數量，就會造成網絡阻塞或是服務器性能無法滿足要求，甚至使整個系統不穩定。
12306成長之路
短短的3年，從2012年春運到2015年春運，12306網站從10億的PV（page views）值增加到297億PV值，PV值成長 30倍；網絡帶寬從 1.5G調整到12G，帶寬成長8倍；而12306的售票量從110萬增加到564萬 ，成長5倍。出票處理能力從 每秒200張提升到 每秒1032張，也是5倍的成長。
PV值的增加是與放票的次數和可出售的票量有關係，例如，2015年PV值是2014年的2.3倍, 原因是放票次數多了5次“秒殺”，另外增加12% 的售票量。由此可見，互聯網流量PV值的增加速度遠遠高於售票量增加的速度。
|
|
尖峯日 PV值 |
放票次數 |
網絡帶寬 |
尖峯日 12306 售票（張） |
同時在線人數限制 |
訂單處理（張/秒） |
|
2012 |
10億 |
4次 |
1.5G |
110萬 |
1萬 |
200 |
|
2013 |
15億 |
10次 |
3G |
265萬 |
20萬 |
450 |
|
2014 |
144億 |
16次 |
5G |
501萬 |
|
1000 |
|
2015 |
297億 |
21次 |
12G |
564萬 |
|
1032 |
12306改造的關鍵技術– 建立可伸縮擴展的雲應用平臺
2015年12306網站順利過關，沒有“癱瘓”，是值得慶祝的。根據互聯網上的新聞，中國鐵道科學研究院電子計算技術研究所副所長，12306網站技術負責人朱建生說，爲了應對2015年春運售票高峯，該網站採取5項措施：一是利用外部雲計算資源分擔系統查詢業務，可根據高峯期業務量的增長按需及時擴充。二是通過雙中心運行的架構，系統內部處理容量擴充一倍，可靠性得到有效保證。三是對系統的互聯網接入帶寬進行擴容，並可根據流量情況快速調整，保證高峯時段旅客順暢訪問網站。四是防範惡意搶票，通過技術手段屏蔽搶票軟件產生的惡意流量，保證網站健康運行，維護互聯網售票秩序。五是制定了多套應急預案，以應對突發情況。
“利用雲計算資源“，“按需及時擴充“和”快速調整“，這幾個字眼是12306改造的精神，其核心就是要建立一個從下到上全面“可伸縮擴展的雲平臺”。底層的硬件架構要支持可伸縮擴展，上層的應用系統架構也需要支持可伸縮擴展。
1. 在過去數年，雲計算的基礎架構虛擬化已經非常成熟，也日益普遍部署；當網絡阻塞時，可以動態增加帶寬，當服務器 CPU到達高位時，可以快速從資源池獲取虛擬機資源來分攤負荷。 “軟件定義的數據中心“ 可以輕易完成這些伸縮性擴展的配置。
2. 當客戶將底層的架構都虛擬化後，網絡設備，Web服務器，應用服務器都可以做“伸縮性”的擴展；但遇到一個難點就是“12306的應用系統框架”無法支持可伸縮擴展。原因是關係型數據庫Sybase無法支持“應用系統”的伸縮擴展。
3. 客戶在過去數年已經投入大筆經費在IT方面的建設，但“系統框架設計”還是沿用10幾年前的三層設計，而且每年都在原來的基礎上做不斷的升級。當業務不斷成長時，數據量也跟着成長，功能越來越多， 但系統性能越來越差。客戶該如何選擇呢 ？是 scale up？ 還是 scale out ？
爲什麼選擇Pivotal Gemfire構建12306的雲應用平臺？
要解決12306春運時高流量高併發的問題，如果單靠硬件升級解決的話，可能需要擴充數十倍的硬件服務器。但在春運以後，又該如何解決服務器過剩的問題呢？
要真正解決“高流量，高併發“的難題是需要從軟件和應用系統層面出發，唯有實現“可擴展的應用雲平臺架構”，靈活和快速熱部署的機制，纔是真正解決高併發訪問的根本。
在經過多次論證和POC測試後， 12306 最後選擇Pivotal Gemfire作爲系統改造的平臺，其主要原因如下：
1. 關聯數據節點設計：可以根據客戶的業務邏輯特性和數據關聯性，將關聯性強的數據放置於同一個服務器節點，提高系統性能，避免分佈式系統服務器的頻繁數據交換。
2. 將數據移到內存：由於數據是放在內存裏面，屏蔽傳統數據庫頻繁訪問， CPU與數據庫的交互作用，影響服務器性能。內存的數據交換速度遠高於磁盤速度上千倍， 極大提高系統性能。
3. 擴展和伸縮性：以Gemfire構建的應用雲平臺，是以 x86 PC服務器爲主的硬件基礎。在保證系統的性能下，此平臺可以隨着客戶業務的成長來任意調配x86服務器的數量，避免以後昂貴的硬件升級帶來的困擾。經POC測試結果顯示，整個系統性能可隨着服務器的數量的增加實現幾乎線性的成長。
4. 數據可靠性：在同個集羣裏面可以有多個數據節點備份，數據可以自動同步，或是將內存數據持久化到硬盤或是數據庫
5. 跨地域的數據分佈或同步 ：可以透過“廣域網”將指定的 Gemfire集羣的內存數據“實時同步”到異地的數據中心。這是屬於“應用層”的數據同步異於傳統的“數據庫”同步。
6. Pivotal Gemfire使用 x86 PC服務器，其性價比遠遠高於 Unix 小型機。
在後續章節，以12306爲案例做進一步分析，使用Pivotal Gemfire會給12306帶來什麼好處。
回顧12306 成長的煩惱
（1）網絡阻塞是個門檻
網絡是進入12306征程的起點，網絡帶寬快慢往往決定“秒殺“的結果，這在很多電商網站促銷時時常發生， 因此12306也無法避免。下面數字是由互聯網收集得到的，可能有偏差。但我們儘可能根據這些數目字來解析數年來網絡原因發生的問題。
- 2012 年：12306 第一次在春運使用， 網絡帶寬1.5G，可以支持最大的PV值是11,250；根據報導，此係統有10,000人的登陸限制， 假如每人每秒點擊一次的話，理論上是可以勉強支持正常的點擊量。
但在購票尖峯日，有上千萬的網民第一次上網購票，在無法登陸的情況下， 用戶不斷刷取首頁，或是已登陸者無法得到系統的及時反應，不斷點擊頁面，產生大量的請求，造成網絡和系統的高負載，導致崩潰。
- 2013年 ：寬帶增加一倍到達3G頻寬，有20萬用戶登陸的限制，採取10次放票，分散流量，防止買票過度集中；但不幸的是“刷票軟件”橫行，每秒可以刷票數十次到數百次，高峯期有25萬的PV值， 遠遠超過帶寬的最大理論值 22,500 PV。
- 2014年 : 寬帶增加到達5G，16次放票，有屏蔽刷票軟件搶票的設計，有效阻擋90%的點擊，但實名制有漏洞，每秒還是有15萬次的瀏覽需求，遠超過37,500 PV的的理論帶寬承載量。
- 2015年 : 12306有21次放票，增加帶寬到12G，手機訂票（流量小）分擔25%的12306售票，解決實名制的問題，可以阻擋95% 刷票軟件的點擊量，每秒最大有117,800次的瀏覽請求，此數目字已經很接近理論帶寬承載量117,400 PV值。
根據上述解析， 2012年 – 2014年春運的網絡帶寬給12306帶來很多問題。根據網民的反應，在2015年12306帶寬在 12G的情況下，雖然稍微有點卡， 但是大致的反應還是不錯的。此輪點與我們的推論是大致符合。
|
|
尖峯日 PV值 |
放票次數 |
尖峯每次放票 平均PV值 |
網絡帶寬 |
帶寬最大理論PV值/秒 |
瀏覽請求最大PV值/秒 |
|
2012 |
10億 |
4次 |
2.5億次 |
1.5G |
11,250 |
10,000 |
|
2013 |
15億 |
10次 |
1.5億次 |
3G |
22,500 |
250,000 |
|
2014 |
144億 |
16次 |
9.0億次 |
5G |
37,500 |
150,000 |
|
2015 |
297億 |
21次 |
14.14億次 |
12G |
117,400 |
117,800 |
2. 2013年與2014年的PV值有10倍的差異， 2014年多了6次放票時段，票的出售量增加90%。但在 2013年，極有可能是大部分的票量集中在少數時段就放完，減少多次的“秒殺“發生。
3. 2012和2013年， 12306 沒有屏蔽搶票軟件的設置。在2014年以後，實現了基本的屏蔽功能。 假設此在2014年可以阻擋90%搶票軟件的點擊， 在2015年可以阻擋 95%的點擊。
4. 在2015年， 假設互聯網的平均PV值的數據量是15K byte， 手機上網的PV值是 1K byte，佔有25%的流量。
5. 帶寬最大理論PV值/秒 ： 1G的帶寬是1,000,000,000 bit/second,1 byte = 8 bits.
2015年平均PV值 =11.5K byte （含手機上網）, 2012-2014年的PV值= 15K bytes。
另外，假設考慮網絡IP協議交換有10%的損耗。
6. 瀏覽請求最大PV值/秒：假設在每個放票時段，搶票的高峯期是5分鐘（含查詢， 下單，付款等操作），在高峯期5分鐘的下載流量是整個時段下載總量50%；
再假設有效的瀏覽下載量是5%上傳的請求點擊量，換句話說，有95%的點擊量被屏蔽，可能是阻擋刷票軟件，或是網絡阻塞丟包，或是系統忙碌沒有反應等等。
（2）服務器集羣性能無法伸縮性擴展
參考互聯網上的資料，12306服務器集羣是傳統的三層架構設計，如果不考慮最前端的F5負載均衡服務器，它是由 數百部 Web服務器集羣和應用服務器集羣構成前端，64部數據庫小型機集羣（用於專門實現並行計算每班車次的餘票量），和訂單處理服務器集羣構成後端。從專業的角度來看，此種框架設計是中規中矩的，國內99%的框架設計師都是如此設計。
如前述所提，由於Sybase數據庫的原因，此種設計無法做伸縮性的擴展。因此，12306要進一步提高性能就面臨很大的抉擇。在此，先了解服務器集羣性能與實際需求之間有多少差距。
回顧2012年到2015年，12306系統在這3年內有很大的變化。
1. 2012年春運 ：根據互聯網上的信息，2012年 12306設計的售票指標是在100萬張票的銷售，這完全低估了互聯網網民的實際需求，在尖峯日，有上千萬人登陸。網絡帶寬，Web服務器集羣，應用服務器集羣，餘票查詢/計算集羣,到訂單處理集羣, 這些設備性能完全無法應付高流量高併發的請求。由於極大的低估互聯網的需求，造成12306整個系統不穩定。
在12306系統，餘票查詢/計算子系統是最複雜的， 最耗損服務器CPU資源。在整個客票系統裏，有數十條行車路線，有3000多個車次（G,D,K,Z,C,..），5000多個火車站，不同的席次（硬座，硬臥， 軟座， 軟臥， etc），座位等級(商務， 一等， 二等)，和車票等級（一般，軍人， 學生，殘障，小孩）等因素，將這些參數換算成數學模型，那可是有數千億條的排列組合。
2012年的餘票計算系統實際處理能力據估計不會超過 300-400 TPS，而有效的餘票查詢請求遠遠高於3000 QPS （query per second）。另外，系統每隔10分鐘更新車次的餘票，這些餘票信息是沒有參考價值，因爲在10分鐘裏已經售出數十萬張票。如果要滿足餘票計算的需求達到至少 3000 TPS， 那麼12306 需要再增加6倍的服務器，即將近 400部小型機（原有系統有64部服務器）。
2. 2013年春運：在2012年6月進行第一步餘票查詢/計算改造，使用Pivotal Gemfire改造後的結果是每秒至少支持 10,000 TPS 以上，此數目字已經足夠應付高併發的需求，因此在2013年春運餘票查詢順利過關。 由於集羣計算能力大增，餘票更新縮短到每隔2分鐘提供最及時的信息。
在餘票查詢瓶頸移除後，訂單處理服務器的瓶頸就出現在訂單排隊，網民必須等待數十秒到數十分鐘纔會得到訂單的確認。訂單的請求累積高達數千甚至數萬個以上，估計當時訂單處理服務器的處理能力不超過 200-300 TPS。
3. 2014年：在2013年後，進行“訂單分庫二級查詢”處理，將訂單生成與訂單查詢分開處理。因爲訂單查詢的數量遠遠超過訂單生成的數量。因此， 12306將查詢訂單的熱點數據放在Gemfire集羣， 將歷史訂單數據放在Hadoop集羣。如此設計，不但提高訂單查詢的功能數十倍，而且訂單生成的性能至少也提高5倍以上（使用原有服務器）。
4. 2015年：進一步使用Gemfire優化整個 12306系統，總共建立5個Gemfire集羣。另外建立三個數據中心（高鐵公司， 鐵科院，和阿里雲），在阿里雲上部署數百個虛擬機（有 Web服務器，應用服務器，和餘票查詢服務器集羣）分流餘票查詢75%的流量，因爲餘票查詢流量佔據12306整體流量的90%。
|
|
平均每次放票量 |
尖峯有效餘票 計算請求（QPS） |
餘票計算能力（TPS） |
尖峯期訂單 處理請求（TPS） |
訂單處理能力（TPS） |
|
2012 |
415,000 |
> 3000 |
300-400 |
》 1600 |
200 |
|
2013 |
265,000 |
> 3000 |
》 10,000 |
》 1030 |
500 |
|
2014 |
313,000 |
> 3000 |
》 10,000 |
1200 |
1000 |
|
2015 |
268,500 |
> 3000 |
》 10,000 |
1050 |
1000 |
使用Gemfire改造後12306的現狀和啓示
2015年的春運購票期間12306系統的表現是很令人矚目的，它的效果和影響總結如下：
1. 提供“高併發，低延遲”的解決方案，一勞永逸，不用煩惱後續硬件升級的問題
2. 通過GemFire多集羣技術，實現多重的高可用性，確保高峯壓力下和系統異常的情況下保證業務的持續性。
3. 構建一個可擴展的雲應用平臺架構，靈活和快速熱部署的機制，爲未來混合雲的部署打基礎。
4. 餘票查詢集羣性能提升 ：
- 使用數十部 x86服務器 （或是上百部虛擬機）可以達到 10,000 TPS以上，提升原來系統性能達30倍以上。原來的系統是使用64部Unix 小型機。
- 餘票信息更新從原來10分鐘縮短到2分鐘，使信息更有參考價值。
5. 12306“訂單分庫二級查詢”子系統：
- 將訂單生成與訂單查詢分庫處理，訂單查詢性能提高50倍， 訂單生成性能提高4-5倍。
- 將熱點訂單放在Gemfire集羣，將歷史訂單數據放在Hadoop集羣。這是快數據和大數據結合的完美案例。
6. 混合雲的應用：
- 使用Gemfire改造後的分佈式系統，極易分散部署到不同的數據中心
- 例如，餘票查詢子系統可以獨立於原來的大系統部署到公有云上，同時也可以再將此子系統一分爲二，將另一部分服務器部署在私有云的數據中心。即按業務需求隨時部署所需要的資源，來解決高併發的難題。