[討論]從12306淺談大型網(wǎng)站架構(gòu)演變之路（獲獎名單已公布）

南非螞蟻

這里總結(jié)下網(wǎng)站架構(gòu)的演變過程：


架構(gòu)演變第一步：物理分離webserver和數(shù)據(jù)庫



架構(gòu)演變第二步：增加頁面緩存


架構(gòu)演變第三步：增加頁面片段緩存

南非螞蟻

架構(gòu)演變第四步：數(shù)據(jù)緩存



架構(gòu)演變第五步：前段增加webserver


架構(gòu)演變第六步：數(shù)據(jù)庫分庫

hbsycw

回復(fù) 52# 南非螞蟻

個人習(xí)慣的架構(gòu)是：WEB Server+APP Server+DB Server, 然后每層再有針對性的實施水平擴展（SCALE OUT）方案。


   

ak47mig

king_819 發(fā)表于 2012-02-23 09:27
回復(fù) 29# liang3391

12306數(shù)據(jù)庫的實時性要求非常高的，數(shù)據(jù)實時刷新的，還緩存，怎么緩存

說到緩存。其實得根據(jù)買票這個業(yè)務(wù)來具體的看。

數(shù)據(jù)是實時刷新的，但是除非購買，不用真正跟數(shù)據(jù)庫交互。
如果只是查詢。一秒鐘更新一次緩存也足夠了，真正訂票的時候大家一秒鐘并發(fā)很高的。

ak47mig

a2433 發(fā)表于 2012-02-22 18:01
上面說按車次 估計不大現(xiàn)實  太麻煩了   我想是不是按 鐵路局  劃分呢   按照所選的車次 自動或者  地點  自 ...

按車次分還好吧。

我覺得我們在這里討論也是外人指路，最好還是有12306的日志看看，哪些車次是高頻率車次�；蛘吒鶕�(jù)鐵路局之前的經(jīng)驗來看，哪些線路可能訂票比較多。對于熱點線路單獨分一個庫我覺得是不為過的。

一些非熱點線路可以根據(jù)負(fù)載情況分到其他庫里。

另外很可能一個線路今天幾個小時就售罄了這個時候數(shù)據(jù)庫就空閑了。可以移出。

ak47mig

sery 發(fā)表于 2012-02-22 18:09
12306使用網(wǎng)宿的cdn，但從它的具體情況得知大部分是動態(tài)對象，不適合網(wǎng)宿那種加速方式。本來訪問的用戶多， ...

對。這種cdn的使用方法還是很傻的。


可能是他們一開始也沒估算好。在設(shè)計的時候沒有完全把動靜態(tài)分開。

把靜態(tài)資源上cdn，保證用戶的瀏覽正常，盡量做小動態(tài)資源部分。我覺得從設(shè)計上還是可以把動態(tài)資源做到最小的。

另外剛才提到的一個極端方法：一個線路一個數(shù)據(jù)庫，我覺得在cdn上也可以做類似的考慮。比如剩余票數(shù)查詢完全可以跟cdn商協(xié)商。也是一秒鐘一更新跟源站取數(shù)據(jù)，但是堅決避免除此之外的回源。

真正讓網(wǎng)站把資源節(jié)省到用戶訂票的寫操作上。

ak47mig

南非螞蟻 發(fā)表于 2012-02-28 09:07
數(shù)據(jù)緩存

其實原理也就是cache，更多的cache和分拆，更合理的分拆。

樓主的哪個設(shè)計只是保證了基本的性能和基礎(chǔ)的冗余性。如果運算本身就是很多，還是需要將負(fù)擔(dān)放在更多機器上去的。所以就是分拆，分庫。

我們不可能把用戶的需求減少：只能將請求減輕（更小數(shù)據(jù)個頭的數(shù)據(jù)量請求，將靜態(tài)請求剝離），更淺（比如非寫入的盡量落到更靠前的cache上）。


另外其實app和database的優(yōu)化在這個時候可能也會更有效一些。

比如是否能把update改成別的方式。起碼mysql的update肯定容易鎖表的。數(shù)據(jù)庫里面的數(shù)據(jù)能否只是簡單的數(shù)據(jù)符號。

ak47mig

齊達內(nèi)553847981 發(fā)表于 2012-02-24 21:19
前端應(yīng)該有 CDN，盡量將靜態(tài)內(nèi)容放到這一級，并配合其他CDN的應(yīng)用模式；下一級負(fù)載均衡應(yīng)該是DNS，將 ...

我倒覺得數(shù)據(jù)庫不一定非得選oracle....當(dāng)然最終的存儲選擇oracle是沒問題的，但是訂票時段并發(fā)太高，oracle性能不適合吧。


其實對于車票這種特殊的應(yīng)用，我覺得可能自己寫個特殊的數(shù)據(jù)庫放在訂票時段用更合適一些。因為車票的特點就是一個人一個坑，一個車次總坑數(shù)是一定的。


而對于訂票來說，訂票時間寫入是高峰，這個寫入只是說讓你入坑而已。所以我覺得不如很多東西錯峰來做（比如校驗用戶的真實性，生成車票相關(guān)信息之類的）：訂票的時候就是讓這些人入坑（可以只是簡單的打log，或者數(shù)據(jù)庫的insert操作，但是會判斷有座無座以免賣超了）。然后等低峰的時候慢慢從log里回放，讓大家選座之類的。這些最終信息再慢慢入總庫。

南非螞蟻

ak47mig 發(fā)表于 2012-02-28 13:20
其實原理也就是cache，更多的cache和分拆，更合理的分拆。

樓主的哪個設(shè)計只是保證了基本的性能和基 ...

分析的很有道理，感謝分享經(jīng)驗！

南非螞蟻

繼續(xù)接52樓

架構(gòu)演變第七步：分表、DAL和分布式緩存





架構(gòu)演變第八步：增加更多的webserver，分布式文件系統(tǒng)




架構(gòu)演變第九步：數(shù)據(jù)讀寫分離加廉價存儲方案