建站
咨詢
售后
建站咨詢
新聞中心
“12306”是如何支撐百萬QPS的？
我想從兩個方面回答這個問題：
1、緩存的使用。大部分通過12306買票的人都有這樣的經(jīng)歷，明明顯示有票，但是下單的時候就提示余票不足，這就是緩存的副作用。不過使用緩存卻也有很大的好處，極大降低了數(shù)據(jù)庫的讀取壓力，可以支持更大的讀吞吐量。對于買票這種場景也是讀遠高于寫，特別是節(jié)假日的車票，很多人一直在刷，實際能下單的卻很少。不過個人認為12306的緩存更新機制應該還有提升空間，目前的緩存更新還是有點慢。
2、隊列的使用。購買節(jié)假日車票的時候也會經(jīng)常遇到排隊的情況，最終有可能買不到票。12306將買票需求加入到隊列，然后一個個的處理，先到先得，這樣可以極大的降低數(shù)據(jù)庫的并發(fā)寫壓力，而且沒有破壞公平原則。
還有一些朋友提到12306使用了阿里云，阿里云因為本身擁有很多的云計算資源，可以按需購買，對于節(jié)假日的購票高峰，12306服務可以很快速的水平擴展，滿足業(yè)務需要，這也是其能夠支撐百萬并發(fā)的一個很重要因素。
首先是分布式架構，全網(wǎng)CDN加速技術，數(shù)據(jù)庫應該是oracle或者DB2的，數(shù)據(jù)庫應該是訂單數(shù)據(jù)庫，用戶數(shù)據(jù)庫，車輛運行線路庫，車票庫，代理商窗口管理用戶庫，日志庫，通過幾個庫的關聯(lián)查詢，并下單購票。
每個庫都有備份。這樣相當于幾個數(shù)據(jù)庫同時協(xié)作，小型系統(tǒng)一般就一個庫，幾個表，也能做到高并發(fā)。它這樣的架構部署，既高效又節(jié)省費用。
最耗資源的一個是余票查詢，一個是高峰訂單寫入，第二個比較容易滿足，隊列再加上橫向拓展處理服務即可，余票查詢很麻煩，涉及到訂單，路線圖等內容的關聯(lián)查詢，oracle rac可以滿足橫向拓展資源，但是結構設計和優(yōu)化需要有寫入和查詢的平衡點，再有就是定期的歸檔業(yè)務庫，保證業(yè)務庫的數(shù)據(jù)量在可控的范圍內
隊列服務也比較重要，消息內容不能太重，還需要一定程度的持久化
個人簡單談一下百萬QPS下的12306如何架構，算是拋磚引玉，下圖是我畫的一張網(wǎng)絡拓撲圖：
我們知道當國慶節(jié)、春節(jié)來臨的時候，12306會在每天的早上8點、12點、16點等各個時間點放票，這時候在極短的時間內涌入大量的流量請求，可是說是中國互聯(lián)網(wǎng)甚至世界互聯(lián)網(wǎng)上最大的高并發(fā)請求量了。
那首先要保證的就是網(wǎng)絡不能掛，大家都先不用考慮服務端具體業(yè)務怎么實現(xiàn)的，應該首先要考慮的是多大的網(wǎng)絡帶寬能夠承受住這么大的請求量？
我們常用的方式就是一個域名解析到一個ip地址，這個ip有可能是SLB，或者我們自己裝的nginx，然后通過slb再將請求均衡分發(fā)到我們的服務器上，這是最簡單常見的負載均衡策略。
但是這樣的單臺機器負載均衡是不可能承受的住12306千百萬級高并發(fā)的。所以必須在域名解析處做好DNS負載均衡，再搭建好SLB集群和Nginx集群，且是多個集群，不同的集群去處理不同的業(yè)務。大家可以看到圖中網(wǎng)絡層，第一步也是最重要的一步就是要把所有的流量均攤出來，避免單機器甚至單集群無法承受住網(wǎng)絡流量的瞬時轟炸導致網(wǎng)站癱瘓。
車票查詢是最核心的業(yè)務，也是請求量最大的業(yè)務，不僅僅自家網(wǎng)站的大量請求查詢，還有一個第三方開發(fā)的搶票軟件也在不斷地請求12306的車票查詢業(yè)務。
下面有別的答主回答說需要用緩存，這是必然的，但也在抱怨明明有票但是就是顯示沒票，或者顯示有票下單時候就提示沒票了。這不是說12306的緩存一致性有問題，或者說這塊只保證高并發(fā)了，對一致性就肯定做不到強一致性了。
分布式系統(tǒng)中的CAP理論大家應該都知道，CAP理論只能同時滿足CP和AP或者CA，其中分區(qū)容忍性不可拋棄，那就剩CP和AP了。所以無法做到高并發(fā)高可用的同時還得做到強一致性。
到此，以上就是小編對于slb負載均衡 nginx的問題就介紹到這了，希望這1點解答對大家有用。
網(wǎng)站欄目：“12306”是如何支撐百萬QPS的？（nginx負載均衡與SLB怎么搭建）
本文來源：http://www.5511xx.com/article/cojhggh.html
