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