註：本文首發於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
高流量除了代表網絡容易造成阻塞以外，系統伺服器也會面臨更高的CPU負載，在此情況下又該如何應對呢？是選擇基於原來系統框架上購買更昂貴的硬體做「scale up「升級呢 ？還是選擇購買低成本的x86伺服器，進行」可擴展雲平臺架構「 scale out的改造設計呢？12306網際網路購票系統的改造給我們一個很好的案例參考，也讓政府單位和企業進一步了解了具體是如何實現的。
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
1.PV值和放票次數是根據網際網路的報導。
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
在12306系統，餘票計算的結果是放在「數據緩存應用伺服器」，在2012年每隔10分鐘更新每班車次的餘票結果。如果新請求與上次更新的時間間隔低於10分鐘，數據緩存系統就直接返回上次計算的結果。而在10分鐘左右再重新計算新的請求。在10分鐘的間隔，伺服器集群需要計算3000多個車次的餘票結果。自2013年以後，12306系統每隔2分鐘更新車次餘票結果。
使用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改造後的分布式系統，極易分散部署到不同的數據中心 例如，餘票查詢子系統可以獨立於原來的大系統部署到公有雲上，同時也可以再將此子系統一分為二，將另一部分伺服器部署在私有雲的數據中心。即按業務需求隨時部署所需要的資源，來解決高並發的難題。作者簡介：劉雲程 （YC），技術總監，任職於資拓宏宇（上海）公司，主要負責提供客戶應用系統升級, 遷移到高性能和高擴展性的「雲應用平臺」。 劉雲程畢業於臺灣清華大學，在美國拿計算機博士，於1994年由IBM外派到北京。他在IT行業有近30年工作經驗，曾任職於IBM中國研究中心負責電子商務和移 動網際網路方面的研究。
（責編/錢曙光）
相關閱讀： 12306上的分布式內存數據技術GemFire
系列文章：
揭秘12306技術改造（三）：傳統框架雲化遷移到內存數據平臺
技術揭秘12306改造（二）：探討12306兩地三中心混合雲架構
技術揭秘12306改造（一）：尖峰日PV值297億下可每秒出票1032張
投稿+諮詢請致郵：qianshg@csdn.net。
>> CSDN雲計算投稿快速通道
本文為CSDN原創文章，未經允許不得轉載，如需轉載請聯繫market#csdn.net(#換成@)