如何設計高并發(fā)高流量的12306在線票務系統(tǒng)

gilet

現在登陸好登陸上了，但是查詢到票提交訂單老是提交不了，提示提交訂單的人多

king_819

這個就是一個FB 工程，層層分包

king_819

對于12306網站，最大的壓力在后端數據庫了，都是實時、動態(tài)的數據，數據庫優(yōu)化很重要

gotolinux

wzs993636 發(fā)表于 2012-01-20 09:20
我覺得吧，正如前面兄弟所說的，這個系統(tǒng)的核心數據庫還是舊的，只是提供相關API給網站使用，所以問題也不能 ...

其實這和數據庫的新舊沒有關系，舊的不等于不好啊。關鍵是數據庫的架構。

comcn2

剛看到這個討論，順手把我發(fā)在其他板塊的帖子轉過來：

第一部分：12306訂票網站的真實業(yè)務壓力分析（假定24小時都可以訂票，并且一次放票完畢）：
1、需要訂票的人群總數是有限的，一個人訂到車票之后，可以認為不會再去訪問這個站點。
2、從網上查到全國流動人口總數大約2.6億。估計其中30%的通過網站訂票（上班的時候能上網的群體比例未必有這么高，另外上網族也不是每個人都在網上訂票）。也就是4800萬，往返計算，就是9600萬，按照訂票一次需要5個PV計算，總的PV數 就是4.8億，春運共計40天，每天的PV數也就是1200萬。按照訂一張票需要1分鐘計算，并發(fā)連接數8333.4個。這個負載無論是對于web服務器還是數據庫都不算很高。也就是說所謂10億的PV大部分都是無效訪問。如果按照鐵道部的說法，每天放票一百萬張，如果定一張票需要5個PV，那就是只有500萬PV。對于互聯網企業(yè)，這個壓力應該不算大了。我們暫且按照1200萬的PV數進行計算。
3、每天1200萬的PV數的網站，如果訪問量始終很平穩(wěn)，貌似就沒有太大的討論價值了。每天所謂的10億PV的真實有效PV也就是這1200萬，之所以為成為10億PV，就是因為頁面無法打開始終進行刷新頁面造成的。
4、由于鐵道部放票的邏輯過于惡心，導致并發(fā)的PV數很高�？梢约僭O并發(fā)訪問數達到1200萬的訪問請求在一個小時內處理完畢，每個用戶1分鐘，需求就可以簡化為：200萬并發(fā)查詢連接、17萬并發(fā)寫入連接，這種情況下，就需要仔細考慮一下系統(tǒng)的架構設計問題了。


第二部分：從技術角度分析：
第一、網絡部分，這個環(huán)節(jié)貌似最簡單，增加帶寬、使用CDN即可，一般會有啥大的問題，即便有也容易解決
第二、系統(tǒng)前端服務器，提供給用戶進行登錄、查詢、訂票、支付的頁面。貌似這個環(huán)節(jié)也比較簡單，使用負載均衡設備搭建服務器群集，簡單的增加服務器就可以平滑的擴展計算能力，另外對業(yè)務系統(tǒng)代碼進行優(yōu)化，這個環(huán)節(jié)就是一個投入的問題，鐵道部這么有錢，估計這個不是問題。
第三、數據庫，用來存儲車票信息的。作為電商前兩個環(huán)節(jié)都是比較容易解決的，最終所有的壓力都會在數據庫環(huán)節(jié)體現出來。根據一般的經驗，數據庫查詢帶來的壓力會遠大于寫入的壓力�？梢钥紤]采用如下手段：
   1、數據庫拆分：根據車票信息進行數據庫的拆分。比如每個鐵路局所屬的車次分別對應一個數據庫，需要的話可以進一步的對數據庫和表進行拆分，從而實現數據庫的負載分擔。
   2、采用讀寫分離，所有的查詢都定向到只讀數據庫，寫操作定向到寫數據庫。
   3、只讀服務器采用群集技術，進一步提高負載能力。1200萬的訪問，其中只有100萬是需要進行寫操作的，只讀服務器采用群集技術有很有必要了。
第四、系統(tǒng)的負載能力必須足夠大，最少預留50%的計算余量，才能確定用戶一次登錄就可以確定是否能夠訂票，而不是不斷的去刷新頁面，最終導致整個系統(tǒng)崩潰。   

總結：
1、這個所謂的問題，其實本身不是一個技術問題，1000萬的設備應該是足夠了，造成這種現象的根本原因是由于非技術因素造成的。

2、要想徹底解決這個問題，訂票邏輯必須改變，否則到2.6億流動人口，每個人都上網訂票的時候，無論你增加什么樣的設備，都不可能解決這個問題了。想想吧，2.6億人，每人刷新500次頁面，多么恐怖的流量哇。

無風之谷

回復 135# comcn2


    回復很詳細啊:wink:

lastfile

層層轉包，到最后用來做的錢就少了

rootsecurity

1230**就目前來看是鐵路+網宿共同建設的龜速網站，廣大互聯網朋友們眼看著這個平臺確很難買的上票。

架構來說個人意見：
全局cdn在這里是舉足輕重的。最好能精確到市。
數據庫設計是比較重要的，畢竟承載了那么多次查詢，個人感覺RAC集群不錯。
網站方面nginx肯定是首選。
日志處理還是用Hadoop吧，這個就現在來說還是效率比較高的。

comcn2

無風之谷 發(fā)表于 2012-01-24 23:23
回復 135# comcn2

給發(fā)個獎品？

comcn2

comcn2 發(fā)表于 2012-01-23 18:26
剛看到這個討論，順手把我發(fā)在其他板塊的帖子轉過來：

第一部分：12306訂票網站的真實業(yè)務壓力分析（假定 ...

如果火車票像機票一樣可以提前30天以上買票，并且一次就放票完畢，這個看起來很2的網站運行的情況就會很好多。

之所以會出現這樣的情況，有幾個非常重要的因素可能是我們沒有考慮到的：

1、各種特殊票種以及優(yōu)先級，團體票，學生票，民工票，往返票，兒童票，內部職工票，通勤票，同樣的車票價格千差萬別，邏輯極其復雜
2、特權票，黨政軍各級領導、中央各部委、中央媒體都是惹不起的部門，必須要預留大量的車票，最終沒賣出去的車票才會放給正規(guī)的售票渠道，種種因素疊加，導致業(yè)務邏輯混亂不堪，而正是這種混亂不看的邏輯可能最終導致系統(tǒng)設計變得極其復雜、低效，最終投入了大量的經費，卻無法實現預期的目標。