問答專欄Q & A COLUMN
個人簡單談一下百萬QPS下的12306如何架構，算是拋磚引玉，下圖是我畫的一張網絡拓撲圖：
我們知道當國慶節(jié)、春節(jié)來臨的時候，12306會在每天的早上8點、12點、16點等各個時間點放票，這時候在極短的時間內涌入大量的流量請求，可是說是中國互聯網甚至世界互聯網上最大的高并發(fā)請求量了。
那首先要保證的就是網絡不能掛，大家都先不用考慮服務端具體業(yè)務怎么實現的，應該首先要考慮的是多大的網絡帶寬能夠承受住這么大的請求量？
我們常用的方式就是一個域名解析到一個ip地址，這個ip有可能是SLB，或者我們自己裝的nginx，然后通過slb再將請求均衡分發(fā)到我們的服務器上，這是最簡單常見的負載均衡策略。
但是這樣的單臺機器負載均衡是不可能承受的住12306千百萬級高并發(fā)的。所以必須在域名解析處做好DNS負載均衡，再搭建好SLB集群和Nginx集群，且是多個集群，不同的集群去處理不同的業(yè)務。大家可以看到圖中網絡層，第一步也是最重要的一步就是要把所有的流量均攤出來，避免單機器甚至單集群無法承受住網絡流量的瞬時轟炸導致網站癱瘓。
車票查詢是最核心的業(yè)務，也是請求量最大的業(yè)務，不僅僅自家網站的大量請求查詢，還有一個第三方開發(fā)的搶票軟件也在不斷地請求12306的車票查詢業(yè)務。
下面有別的答主回答說需要用緩存，這是必然的，但也在抱怨明明有票但是就是顯示沒票，或者顯示有票下單時候就提示沒票了。這不是說12306的緩存一致性有問題，或者說這塊只保證高并發(fā)了，對一致性就肯定做不到強一致性了。
分布式系統(tǒng)中的CAP理論大家應該都知道，CAP理論只能同時滿足CP和AP或者CA，其中分區(qū)容忍性不可拋棄，那就剩CP和AP了。所以無法做到高并發(fā)高可用的同時還得做到強一致性。
另外12306也不是一次就放票出來的，需要保證車站有票、各個小站點保留一部分票，再分時間段逐次發(fā)放，既然做不到所有人都可以買到自己最想買到的那一張票，那就保證整體大部分用戶買票體驗嘛。
大家都知道國家在治理洪水的時候，會在河流的各個地方設立大壩，逐級控制水流量，而不會把所有的水都蓄在一個地方，水位低的時候，一個大壩就搞定了，水位高的時候，各級大壩都儲蓄一部分水，控制整體的洪流，這樣就很少發(fā)生嚴重的大范圍的洪災了。
網絡也是如此，將整體的網絡流量請求逐級分發(fā)、均衡到各層，能在這層處理的就不要在傳遞到下一層，盡量保證整體的服務高可用，即使損失一些強一致性，只要保證最終的一致性就好了。
這里我沒有講各個點的技術細節(jié)，只說了個人理解的一個整體思想，按照這個思路去做整體的架構，每一個環(huán)節(jié)做到編碼質量最優(yōu)、高可用、高并發(fā)，再整體串起來，即可承載百萬QPS的訪問。
以上就是個人的一些拙見，當然實際上的12306遠比我說的這些要復雜的多。這里就當拋磚引玉了，歡迎各位大佬批評指正，討論學習，共同成長！
評論0
加載中...
首先是分布式架構，全網CDN加速技術，數據庫應該是oracle或者DB2的，數據庫應該是訂單數據庫，用戶數據庫，車輛運行線路庫，車票庫，代理商窗口管理用戶庫，日志庫，通過幾個庫的關聯查詢，并下單購票。
每個庫都有備份。這樣相當于幾個數據庫同時協(xié)作，小型系統(tǒng)一般就一個庫，幾個表，也能做到高并發(fā)。它這樣的架構部署，既高效又節(jié)省費用。
評論0
加載中...
我想從兩個方面回答這個問題：
1、緩存的使用。大部分通過12306買票的人都有這樣的經歷，明明顯示有票，但是下單的時候就提示余票不足，這就是緩存的副作用。不過使用緩存卻也有很大的好處，極大降低了數據庫的讀取壓力，可以支持更大的讀吞吐量。對于買票這種場景也是讀遠高于寫，特別是節(jié)假日的車票，很多人一直在刷，實際能下單的卻很少。不過個人認為12306的緩存更新機制應該還有提升空間，目前的緩存更新還是有點慢。
2、隊列的使用。購買節(jié)假日車票的時候也會經常遇到排隊的情況，最終有可能買不到票。12306將買票需求加入到隊列，然后一個個的處理，先到先得，這樣可以極大的降低數據庫的并發(fā)寫壓力，而且沒有破壞公平原則。
還有一些朋友提到12306使用了ucloud云，ucloud云因為本身擁有很多的云計算資源，可以按需購買，對于節(jié)假日的購票高峰，12306服務可以很快速的水平擴展，滿足業(yè)務需要，這也是其能夠支撐百萬并發(fā)的一個很重要因素。
評論0
加載中...
最耗資源的一個是余票查詢，一個是高峰訂單寫入，第二個比較容易滿足，隊列再加上橫向拓展處理服務即可，余票查詢很麻煩，涉及到訂單，路線圖等內容的關聯查詢，oracle rac可以滿足橫向拓展資源，但是結構設計和優(yōu)化需要有寫入和查詢的平衡點，再有就是定期的歸檔業(yè)務庫，保證業(yè)務庫的數據量在可控的范圍內
隊列服務也比較重要，消息內容不能太重，還需要一定程度的持久化
評論0
加載中...
從我掌握的消息，12306采用混合云架構，最耗資源的其實是余票查詢，這一塊ucloud云和電信云差不多各占一半，交易那塊就屬于自己的私有云。
評論0
加載中...
12306余票查詢系統(tǒng)依托ucloud云的算法實現大并發(fā)情況下的數據處理，可以支撐當前突發(fā)的大流程訂票業(yè)務，ucloud云威武
評論0
加載中...0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答
