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倍，這樣海量的請求，假如不能在短時間內動態調整網絡帶寬或增加服務器數量，就會造成網絡阻塞或是服務器性能無法滿足要求，甚 至使整個系統不穩定。
短短的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互 聯網購票系統的改造給我們一個很好的案例參考，也讓政府單位和企業進一步了解了具體是如何實現的。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帶來什麼好處。
（1）網絡阻塞是個門檻
網絡是進入12306征程的起點，網絡帶寬快慢往往決定“秒殺“的結果，這在很多電商網站促銷時時常發生， 因此12306也無法避免。下面數字是由互聯網收集得到的，可能有偏差。但我們盡可能根據這些數目字來解析數年來網絡原因發生的問題。
但在購票尖峰日，有上千萬的網民第一次上網購票，在無法登陸的情況下， 用戶不斷刷取首頁，或是已登陸者無法得到系統的及時反應，不斷點擊頁面，產生大量的請求，造成網絡和系統的高負載，導致崩潰。
根據上述解析， 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分鐘更新車次余票結果。2015年的春運購票期間12306系統的表現是很令人矚目的，它的效果和影響總結如下：
1. 提供“高並發，低延遲”的解決方案，一勞永逸，不用煩惱後續硬件升級的問題
2. 通過GemFire多集群技術，實現多重的高可用性，確保高峰壓力下和系統異常的情況下保證業務的持續性。
3. 構建一個可擴展的雲應用平台架構，靈活和快速熱部署的機制，為未來混合雲的部署打基礎。
4. 余票查詢集群性能提升 ：
5. 12306“訂單分庫二級查詢”子系統：
6. 混合雲的應用：
