怎么從技術的角度去分析12306實現(xiàn)高流量高并發(fā)的問題

來源：易賢網(wǎng) 閱讀：1312 次日期：2016-07-06 08:45:35

溫馨提示：易賢網(wǎng)小編為您整理了“怎么從技術的角度去分析12306實現(xiàn)高流量高并發(fā)的問題”,方便廣大網(wǎng)友查閱！

大家都知道，買票都到12306，這么多的訪問量竟然沒癱瘓，他是怎么做到的，記者在第一時間聯(lián)系到一位對12306改造非常關注的技術架構師，他從技術的角度來給我們做具體的分析，需要的朋友可以參考下

12306網(wǎng)站曾被認為是“全球最忙碌的網(wǎng)站”，在應對高并發(fā)訪問處理方面，曾備受網(wǎng)民詬病。因此記者在第一時間聯(lián)系到一位對12306改造非常關注的技術架構師，他從技術的角度，用科學論證的方式，指出原因所在，并根據(jù)他的經(jīng)驗進一步說明12306是如何實現(xiàn)高流量高并發(fā)的關鍵技術，與大家共享。以下為正文：

前言：

12306互聯(lián)網(wǎng)售票系統(tǒng)在2011年下半年開始上線使用，但在2012年春運期間引發(fā)無數(shù)的爭議。在2012年春運后，12306項目承接單位與多家IT公司聯(lián)系，經(jīng)過多次論證和POC 測試，最終引入分布式內存運算數(shù)據(jù)管理云平臺 - Pivotal Gemfire做試點，用以提高12306系統(tǒng)性能，解決“高流量和高并發(fā)“的難題。

高流量高并發(fā)是指某特定時間段的海量請求，根據(jù)過去的經(jīng)驗法則，高并發(fā)是指訪問流量是平常流量的 3-5倍;但由于互聯(lián)網(wǎng)和移動設備apps的普遍化，電商網(wǎng)站的促銷模式“11.11“，或是廠商的“饑餓營銷“，都會衍生“秒殺“現(xiàn)象。所以過去的經(jīng)驗法則用到12306春運售票系統(tǒng)，往往是遠遠低于實際的的流量。例如，12306平常一天的PV(page views)值大約是在 2500萬到 3000萬左右，在2015年春運高峰日的PV值是297億，流量增加1000倍，這樣海量的請求，假如不能在短時間內動態(tài)調整網(wǎng)絡帶寬或增加服務器數(shù)量，就會造成網(wǎng)絡阻塞或是服務器性能無法滿足要求，甚至使整個系統(tǒng)不穩(wěn)定。

12306成長之路

短短的3年，從2012年春運到2015年春運，12306網(wǎng)站從10億的PV(page views)值增加到297億PV值，PV值成長 30倍;網(wǎng)絡帶寬從 1.5G調整到12G，帶寬成長8倍;而12306的售票量從110萬增加到564萬，成長5倍。出票處理能力從每秒200張?zhí)嵘?每秒1032張，也是5倍的成長。

PV值的增加是與放票的次數(shù)和可出售的票量有關系，例如，2015年PV值是2014年的2.3倍, 原因是放票次數(shù)多了5次“秒殺”，另外增加12% 的售票量。由此可見，互聯(lián)網(wǎng)流量PV值的增加速度遠遠高于售票量增加的速度。

高流量除了代表網(wǎng)絡容易造成阻塞以外，系統(tǒng)服務器也會面臨更高的CPU負載，在此情況下又該如何應對呢?是選擇基于原來系統(tǒng)框架上購買更昂貴的硬件做“scale up“升級呢 ?還是選擇購買低成本的x86服務器，進行”可擴展云平臺架構“ scale out的改造設計呢?12306互聯(lián)網(wǎng)購票系統(tǒng)的改造給我們一個很好的案例參考，也讓政府單位和企業(yè)進一步了解了具體是如何實現(xiàn)的。

12306改造的關鍵技術– 建立可伸縮擴展的云應用平臺

2015年12306網(wǎng)站順利過關，沒有“癱瘓”，是值得慶祝的。根據(jù)互聯(lián)網(wǎng)上的新聞，中國鐵道科學研究院電子計算技術研究所副所長，12306網(wǎng)站技術負責人朱建生說，為了應對2015年春運售票高峰，該網(wǎng)站采取5項措施：一是利用外部云計算資源分擔系統(tǒng)查詢業(yè)務，可根據(jù)高峰期業(yè)務量的增長按需及時擴充。二是通過雙中心運行的架構，系統(tǒng)內部處理容量擴充一倍，可靠性得到有效保證。三是對系統(tǒng)的互聯(lián)網(wǎng)接入帶寬進行擴容，并可根據(jù)流量情況快速調整，保證高峰時段旅客順暢訪問網(wǎng)站。四是防范惡意搶票，通過技術手段屏蔽搶票軟件產(chǎn)生的惡意流量，保證網(wǎng)站健康運行，維護互聯(lián)網(wǎng)售票秩序。五是制定了多套應急預案，以應對突發(fā)情況。

“利用云計算資源“，“按需及時擴充“和”快速調整“，這幾個字眼是12306改造的精神，其核心就是要建立一個從下到上全面“可伸縮擴展的云平臺”。底層的硬件架構要支持可伸縮擴展，上層的應用系統(tǒng)架構也需要支持可伸縮擴展。

1. 在過去數(shù)年，云計算的基礎架構虛擬化已經(jīng)非常成熟，也日益普遍部署;當網(wǎng)絡阻塞時，可以動態(tài)增加帶寬，當服務器 CPU到達高位時，可以快速從資源池獲取虛擬機資源來分攤負荷。 “軟件定義的數(shù)據(jù)中心“ 可以輕易完成這些伸縮性擴展的配置。

2. 當客戶將底層的架構都虛擬化后，網(wǎng)絡設備，Web服務器，應用服務器都可以做“伸縮性”的擴展;但遇到一個難點就是“12306的應用系統(tǒng)框架”無法支持可伸縮擴展。原因是關系型數(shù)據(jù)庫Sybase無法支持“應用系統(tǒng)”的伸縮擴展。

3. 客戶在過去數(shù)年已經(jīng)投入大筆經(jīng)費在IT方面的建設，但“系統(tǒng)框架設計”還是沿用10幾年前的三層設計，而且每年都在原來的基礎上做不斷的升級。當業(yè)務不斷成長時，數(shù)據(jù)量也跟著成長，功能越來越多，但系統(tǒng)性能越來越差?？蛻粼撊绾芜x擇呢 ?是 scale up? 還是 scale out ?

為什么選擇Pivotal Gemfire構建12306的云應用平臺?

要解決12306春運時高流量高并發(fā)的問題，如果單靠硬件升級解決的話，可能需要擴充數(shù)十倍的硬件服務器。但在春運以后，又該如何解決服務器過剩的問題呢?

要真正解決“高流量，高并發(fā)“的難題是需要從軟件和應用系統(tǒng)層面出發(fā)，唯有實現(xiàn)“可擴展的應用云平臺架構”，靈活和快速熱部署的機制，才是真正解決高并發(fā)訪問的根本。

在經(jīng)過多次論證和POC測試后， 12306 最后選擇Pivotal Gemfire作為系統(tǒng)改造的平臺，其主要原因如下：

1. 關聯(lián)數(shù)據(jù)節(jié)點設計：可以根據(jù)客戶的業(yè)務邏輯特性和數(shù)據(jù)關聯(lián)性，將關聯(lián)性強的數(shù)據(jù)放置于同一個服務器節(jié)點，提高系統(tǒng)性能，避免分布式系統(tǒng)服務器的頻繁數(shù)據(jù)交換。

2. 將數(shù)據(jù)移到內存：由于數(shù)據(jù)是放在內存里面，屏蔽傳統(tǒng)數(shù)據(jù)庫頻繁訪問， CPU與數(shù)據(jù)庫的交互作用，影響服務器性能。內存的數(shù)據(jù)交換速度遠高于磁盤速度上千倍，極大提高系統(tǒng)性能。

3. 擴展和伸縮性：以Gemfire構建的應用云平臺，是以 x86 PC服務器為主的硬件基礎。在保證系統(tǒng)的性能下，此平臺可以隨著客戶業(yè)務的成長來任意調配x86服務器的數(shù)量，避免以后昂貴的硬件升級帶來的困擾。經(jīng)POC測試結果顯示，整個系統(tǒng)性能可隨著服務器的數(shù)量的增加實現(xiàn)幾乎線性的成長。

4. 數(shù)據(jù)可靠性：在同個集群里面可以有多個數(shù)據(jù)節(jié)點備份，數(shù)據(jù)可以自動同步，或是將內存數(shù)據(jù)持久化到硬盤或是數(shù)據(jù)庫

5. 跨地域的數(shù)據(jù)分布或同步：可以透過“廣域網(wǎng)”將指定的 Gemfire集群的內存數(shù)據(jù)“實時同步”到異地的數(shù)據(jù)中心。這是屬于“應用層”的數(shù)據(jù)同步異于傳統(tǒng)的“數(shù)據(jù)庫”同步。

6. Pivotal Gemfire使用 x86 PC服務器，其性價比遠遠高于 Unix 小型機。

(1)網(wǎng)絡阻塞是個門檻

網(wǎng)絡是進入12306征程的起點，網(wǎng)絡帶寬快慢往往決定“秒殺“的結果，這在很多電商網(wǎng)站促銷時時常發(fā)生，因此12306也無法避免。下面數(shù)字是由互聯(lián)網(wǎng)收集得到的，可能有偏差。但我們盡可能根據(jù)這些數(shù)目字來解析數(shù)年來網(wǎng)絡原因發(fā)生的問題。

2012 年：12306 第一次在春運使用，網(wǎng)絡帶寬1.5G，可以支持最大的PV值是11,250;根據(jù)報導，此系統(tǒng)有10,000人的登陸限制，假如每人每秒點擊一次的話，理論上是可以勉強支持正常的點擊量。

但在購票尖峰日，有上千萬的網(wǎng)民第一次上網(wǎng)購票，在無法登陸的情況下，用戶不斷刷取首頁，或是已登陸者無法得到系統(tǒng)的及時反應，不斷點擊頁面，產(chǎn)生大量的請求，造成網(wǎng)絡和系統(tǒng)的高負載，導致崩潰。

2013年：寬帶增加一倍到達3G頻寬，有20萬用戶登陸的限制，采取10次放票，分散流量，防止買票過度集中;但不幸的是“刷票軟件”橫行，每秒可以刷票數(shù)十次到數(shù)百次，高峰期有25萬的PV值，遠遠超過帶寬的最大理論值 22,500 PV。

2014年 : 寬帶增加到達5G，16次放票，有屏蔽刷票軟件搶票的設計，有效阻擋90%的點擊，但實名制有漏洞，每秒還是有15萬次的瀏覽需求，遠超過37,500 PV的的理論帶寬承載量。

2015年 : 12306有21次放票，增加帶寬到12G，手機訂票(流量小)分擔25%的12306售票，解決實名制的問題，可以阻擋95% 刷票軟件的點擊量，每秒最大有117,800次的瀏覽請求，此數(shù)目字已經(jīng)很接近理論帶寬承載量117,400 PV值。

根據(jù)上述解析， 2012年 – 2014年春運的網(wǎng)絡帶寬給12306帶來很多問題。根據(jù)網(wǎng)民的反應，在2015年12306帶寬在 12G的情況下，雖然稍微有點卡，但是大致的反應還是不錯的。此輪點與我們的推論是大致符合。

1. PV值和放票次數(shù)是根據(jù)互聯(lián)網(wǎng)的報導。

2. 2013年與2014年的PV值有10倍的差異， 2014年多了6次放票時段，票的出售量增加90%。但在 2013年，極有可能是大部分的票量集中在少數(shù)時段就放完，減少多次的“秒殺“發(fā)生。

3. 2012和2013年， 12306 沒有屏蔽搶票軟件的設置。在2014年以后，實現(xiàn)了基本的屏蔽功能。假設此在2014年可以阻擋90%搶票軟件的點擊，在2015年可以阻擋 95%的點擊。

4. 在2015年，假設互聯(lián)網(wǎng)的平均PV值的數(shù)據(jù)量是15K byte，手機上網(wǎng)的PV值是 1K byte，占有25%的流量。

5. 帶寬最大理論PV值/秒： 1G的帶寬是1,000,000,000 bit/second,1 byte = 8 bits.

2015年平均PV值 =11.5K byte (含手機上網(wǎng)), 2012-2014年的PV值= 15K bytes。

另外，假設考慮網(wǎng)絡IP協(xié)議交換有10%的損耗。

6. 瀏覽請求最大PV值/秒：假設在每個放票時段，搶票的高峰期是5分鐘(含查詢，下單，付款等操作)，在高峰期5分鐘的下載流量是整個時段下載總量50%;

再假設有效的瀏覽下載量是5%上傳的請求點擊量，換句話說，有95%的點擊量被屏蔽，可能是阻擋刷票軟件，或是網(wǎng)絡阻塞丟包，或是系統(tǒng)忙碌沒有反應等等。

(2)服務器集群性能無法伸縮性擴展

參考互聯(lián)網(wǎng)上的資料，12306服務器集群是傳統(tǒng)的三層架構設計，如果不考慮最前端的F5負載均衡服務器，它是由數(shù)百部 Web服務器集群和應用服務器集群構成前端，64部數(shù)據(jù)庫小型機集群(用于專門實現(xiàn)并行計算每班車次的余票量)，和訂單處理服務器集群構成后端。從專業(yè)的角度來看，此種框架設計是中規(guī)中矩的，國內99%的框架設計師都是如此設計。

如前述所提，由于Sybase數(shù)據(jù)庫的原因，此種設計無法做伸縮性的擴展。因此，12306要進一步提高性能就面臨很大的抉擇。在此，先了解服務器集群性能與實際需求之間有多少差距。

回顧2012年到2015年，12306系統(tǒng)在這3年內有很大的變化。

1. 2012年春運：根據(jù)互聯(lián)網(wǎng)上的信息，2012年 12306設計的售票指標是在100萬張票的銷售，這完全低估了互聯(lián)網(wǎng)網(wǎng)民的實際需求，在尖峰日，有上千萬人登陸。網(wǎng)絡帶寬，Web服務器集群，應用服務器集群，余票查詢/計算集群,到訂單處理集群, 這些設備性能完全無法應付高流量高并發(fā)的請求。由于極大的低估互聯(lián)網(wǎng)的需求，造成12306整個系統(tǒng)不穩(wěn)定。

在12306系統(tǒng)，余票查詢/計算子系統(tǒng)是最復雜的，最耗損服務器CPU資源。在整個客票系統(tǒng)里，有數(shù)十條行車路線，有3000多個車次(G,D,K,Z,C,..)，5000多個火車站，不同的席次(硬座，硬臥，軟座，軟臥， etc)，座位等級(商務，一等，二等)，和車票等級(一般，軍人，學生，殘障，小孩)等因素，將這些參數(shù)換算成數(shù)學模型，那可是有數(shù)千億條的排列組合。

2012年的余票計算系統(tǒng)實際處理能力據(jù)估計不會超過 300-400 TPS，而有效的余票查詢請求遠遠高于3000 QPS (query per second)。另外，系統(tǒng)每隔10分鐘更新車次的余票，這些余票信息是沒有參考價值，因為在10分鐘里已經(jīng)售出數(shù)十萬張票。如果要滿足余票計算的需求達到至少 3000 TPS，那么12306 需要再增加6倍的服務器，即將近 400部小型機(原有系統(tǒng)有64部服務器)。

2. 2013年春運：在2012年6月進行第一步余票查詢/計算改造，使用Pivotal Gemfire改造后的結果是每秒至少支持 10,000 TPS 以上，此數(shù)目字已經(jīng)足夠應付高并發(fā)的需求，因此在2013年春運余票查詢順利過關。由于集群計算能力大增，余票更新縮短到每隔2分鐘提供最及時的信息。

在余票查詢瓶頸移除后，訂單處理服務器的瓶頸就出現(xiàn)在訂單排隊，網(wǎng)民必須等待數(shù)十秒到數(shù)十分鐘才會得到訂單的確認。訂單的請求累積高達數(shù)千甚至數(shù)萬個以上，估計當時訂單處理服務器的處理能力不超過 200-300 TPS。

3. 2014年：在2013年后，進行“訂單分庫二級查詢”處理，將訂單生成與訂單查詢分開處理。因為訂單查詢的數(shù)量遠遠超過訂單生成的數(shù)量。因此， 12306將查詢訂單的熱點數(shù)據(jù)放在Gemfire集群，將歷史訂單數(shù)據(jù)放在Hadoop集群。如此設計，不但提高訂單查詢的功能數(shù)十倍，而且訂單生成的性能至少也提高5倍以上(使用原有服務器)。

4. 2015年：進一步使用Gemfire優(yōu)化整個 12306系統(tǒng)，總共建立5個Gemfire集群。另外建立三個數(shù)據(jù)中心(高鐵公司，鐵科院，和阿里云)，在阿里云上部署數(shù)百個虛擬機(有 Web服務器，應用服務器，和余票查詢服務器集群)分流余票查詢75%的流量，因為余票查詢流量占據(jù)12306整體流量的90%。

平均每次放票量尖峰有效余票

計算請求(QPS)余票計算能力(TPS)尖峰期訂單

處理請求(TPS)訂單處理能力(TPS)

2012415,000> 3000300-400》 1600200

2013265,000> 3000》 10,000》 1030500

2014313,000> 3000》 10,000 12001000

2015268,500> 3000》 10,00010501000

在12306系統(tǒng)，余票計算的結果是放在“數(shù)據(jù)緩存應用服務器”，在2012年每隔10分鐘更新每班車次的余票結果。如果新請求與上次更新的時間間隔低于10分鐘，數(shù)據(jù)緩存系統(tǒng)就直接返回上次計算的結果。而在10分鐘左右再重新計算新的請求。在10分鐘的間隔，服務器集群需要計算3000多個車次的余票結果。自2013年以后，12306系統(tǒng)每隔2分鐘更新車次余票結果。

使用Gemfire改造后12306的現(xiàn)狀和啟示

2015年的春運購票期間12306系統(tǒng)的表現(xiàn)是很令人矚目的，它的效果和影響總結如下：

1. 提供“高并發(fā)，低延遲”的解決方案，一勞永逸，不用煩惱后續(xù)硬件升級的問題

2. 通過GemFire多集群技術，實現(xiàn)多重的高可用性，確保高峰壓力下和系統(tǒng)異常的情況下保證業(yè)務的持續(xù)性。

3. 構建一個可擴展的云應用平臺架構，靈活和快速熱部署的機制，為未來混合云的部署打基礎。

4. 余票查詢集群性能提升：

使用數(shù)十部 x86服務器 (或是上百部虛擬機)可以達到 10,000 TPS以上，提升原來系統(tǒng)性能達30倍以上。原來的系統(tǒng)是使用64部Unix 小型機。

余票信息更新從原來10分鐘縮短到2分鐘，使信息更有參考價值。

5. 12306“訂單分庫二級查詢”子系統(tǒng)：

將訂單生成與訂單查詢分庫處理，訂單查詢性能提高50倍，訂單生成性能提高4-5倍。

將熱點訂單放在Gemfire集群，將歷史訂單數(shù)據(jù)放在Hadoop集群。這是快數(shù)據(jù)和大數(shù)據(jù)結合的完美案例。

6. 混合云的應用：