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

haizilin

考慮負載均衡？由主服務(wù)器分發(fā)用戶訪問請求到其所在區(qū)域的子服務(wù)器系統(tǒng)，從而減輕主服務(wù)器壓力。

歸隱鄉(xiāng)村

技術(shù)高的人就是厲害！膜拜下！回復(fù) 8# yanyangtian4502


   

pplong

gotolinux 發(fā)表于 2012-01-17 19:04
我認為這篇討論大部分地方可以參考：http://72891.cn/thread-3626937-7-1.html

主要值得提出來 ...

12306這個傻系統(tǒng)設(shè)計的時候就沒有仔細考慮用戶的行為，后來竟然給自己制造擁塞。還有不能實現(xiàn)充值，導(dǎo)致用戶訂票時間等待時間長，浪費系統(tǒng)資源。

rabbitdjh

    12306這個系統(tǒng)絕非多數(shù)人想像的那么簡單，其實前端的門戶并發(fā)量的提高這塊，大家提到的意見基本上都很到位。
    這個系統(tǒng)關(guān)鍵的地方是票務(wù)交易這塊，這塊由于訂票業(yè)務(wù)的自身屬性，存在著較大的優(yōu)化局限性。具體的說，訂票過程中，不可避免的會產(chǎn)生大量的交易鎖。
    舉例說明：比如某個具體車次的票，當(dāng)一個人搶到一張票后，系統(tǒng)為該張票創(chuàng)建一個臨時鎖，只有當(dāng)用戶支付成功后，交易才會成功；如果交易超過一定時間（比如30分鐘）用戶還沒有進行支付，系統(tǒng)則會回滾該交易。只有這兩種情況之一發(fā)生后，系統(tǒng)才會解除這個臨時鎖。
    所以用戶大量頻繁的訂票交易，數(shù)據(jù)庫會不斷創(chuàng)建大量的交易鎖。這種交易鎖會急劇降低數(shù)據(jù)庫的性能，降低系統(tǒng)的并發(fā)性。
     

ahnhhh

其實完全可以考資金充值到系統(tǒng)，鐵路部門何樂而不為呢，呵呵！就這么簡單！

E8software

這個是關(guān)系到民生的系統(tǒng)，怎么他們做得那么稀爛。解決方案：1.提高硬件性能，2，估計的大改框架，3，提升運維管理能力，運維管理沒有解決掉，其他的都是白搭。

http://www.chinae8.net/cn/cpzx/info_4.aspx?subnavID=125

機器貓II

白癡連樣式都沒有分離你還指望他搞緩存，讀寫分離，CDN

wread

集群、redis，這些啥的，都是術(shù)的概念，解決不了問題。

必須研究業(yè)務(wù)，才可對癥下藥。剛剛看了12360訂票的流程。
先看看第一部分，車票查詢。

主要查詢條件：時間、地點、車票往返。

說白了就是車次，其中涉及到數(shù)據(jù)一致性，車票剩余數(shù)量(可略有誤差)。
其實剩余數(shù)量稍有偏差是沒有關(guān)系的，最后得由購買的最后動作確定結(jié)果。

1.車次的緩存，形成車次查詢結(jié)果列表
車次預(yù)知，數(shù)據(jù)量不大，不超過2G， ，99.99999%的查詢操作。
查詢支持內(nèi)存查詢，多條件,選擇mongodb。
如果并發(fā)量大，可以考慮mongodb的負載均衡。

2.查詢列表的剩余票數(shù)處理
異步從關(guān)系數(shù)據(jù)庫中獲取剩余票數(shù)。

3.車次關(guān)系數(shù)據(jù)庫的切分
根據(jù)車次主鍵奇偶性[可拓展]，進行水平切分存儲，為2的查詢性能進行優(yōu)化。

后續(xù)部分再討論，還沒有看完整的流程。


   

海淀輝哥

我覺得忽略本身程序問題的話!!!可以參考下淘寶的方法 前端上一個緩存 前端lvs 中間加nginx和jobbs實現(xiàn)動靜分離 結(jié)合cdn訪問完全沒有問題了 瓶頸在于數(shù)據(jù)庫 應(yīng)該實現(xiàn)大型讀寫分離 結(jié)合之前的一個金融系統(tǒng)mysql讀寫1:9 我們在去ioe大運動下 肯定得上一套分布式系統(tǒng)可以使用hadoop 或TFS  

海淀輝哥

照搬淘寶