關(guān)于12306網(wǎng)站和清華某院長的微博言論，我做了一個回復(fù)，說這玩意不難，2個人2周，40臺服務(wù)器可以搞定。

下面詳細(xì)解釋一下大概的思路。免費share一下，看看靠譜不靠譜。

別人看到的是流量，我先看結(jié)構(gòu)，這里的數(shù)據(jù)結(jié)構(gòu)是相當(dāng)簡單的，主要滿足的需求是

1.車次查詢（最常見的是起點站，終點站查詢 和車次直接輸入查詢）+余票顯示

所謂的用戶刷頁面，絕大部分應(yīng)該在這里。日均10億pv（這個數(shù)字我先質(zhì)疑一下，不過么關(guān)系，后面再說怎么處理），估計主要落在這個查詢上。

2.注冊，登陸。每天過千萬人次是有的

3.下單，也就是日成交訂單量，可能存在下單失敗，約幾百萬次。

這里基本不涉及復(fù)雜的關(guān)系操作，不涉及推拉結(jié)構(gòu)，和新浪微博，facebook這樣的應(yīng)用場景相比，在數(shù)據(jù)關(guān)系上簡直毫無難度，這也才是我敢說大話的原因。

因為不涉及復(fù)雜的關(guān)系操作，不涉及個性展示（不同用戶搜索同樣的條件，結(jié)果一致），那么緩存化就是最佳途徑。

1.存儲key-value化, 推薦redis

基本上查詢都是直線式的，所以key-value就是很好的工具；因為出票可能需要找一下車次，座位，只能一一對應(yīng)的查詢就不好用；弄個redis 帶個列表結(jié)構(gòu)（dict or zset ，哪個結(jié)構(gòu)更合適？問問新浪架構(gòu)師楊衛(wèi)華吧，這事估計對他太簡單了）進去就可以了。春節(jié)放票總共多少張?又不是一次放出來，每張票對應(yīng)一個key，一個 value，能吃多少內(nèi)存？后面跟個數(shù)據(jù)庫做同步，這點數(shù)據(jù)量對于現(xiàn)在的服務(wù)器來說根本不是問題。

注冊登陸也可以在 mysql基礎(chǔ)上弄個redis掛在前頭響應(yīng)，這種查詢速度，biu.

根據(jù)不同車次分幾臺服務(wù)器，響應(yīng)速度根本不是問題。

2.將所有查詢結(jié)果緩存化，靜態(tài)化

首先明確一下查詢的步驟，實際上主要查詢分兩步

第一步是查詢符合要求的車次，第二步是查詢余票。

緩存也就分兩步做，起始地，目標(biāo)地查詢 - 常見查詢目標(biāo)（如北京到成都）全部預(yù)制緩存。非常見查詢目標(biāo)，基于第一次查詢的結(jié)果緩存，這樣查詢車次基本上無壓力。

查詢有票狀態(tài)就更簡單了，因為票數(shù)只有有票，無票兩個狀態(tài)，某日某車次作為一個key-value類型存儲（仍用redis即可）。某類車票發(fā)生從 有到無或從無到有的變化，才通知緩存更新。更新是后臺通知的，而非基于用戶查詢。比如某車次硬臥票售完，通知一次更新，硬座售完，通知一次更新，軟座售 完，通知一次更新。以此類推，這樣的緩存更新次數(shù)極少。而且可以給前端返回甚至靜態(tài)結(jié)果（基于查詢條件生成靜態(tài)結(jié)果，是個Seoer都會的，后臺在票數(shù)變 化時通知更新，這樣結(jié)構(gòu)上就與前端查詢無關(guān)了，而且一樣可以保持實時性）。

如果你較真說，其實一個車次在不同區(qū)間也存在有無票的不同，的確，不過按照同樣思路，結(jié)構(gòu)多做一層死不了人的。畢竟這只是概述。但是核心思路不變，緩存的變更次數(shù)遠(yuǎn)少于查詢請求次數(shù)，這就夠了。

3.前端緩存處理

很多人被10億請求數(shù)嚇到了，其實這里水分很大，最多的是重復(fù)刷新和外掛工具，那么如果你做到基于2的查詢結(jié)果緩存化，這一步就簡單了;直接參見這 個文章 http://blog.sina.com.cn/s/blog_466c66400100bi2y.html 大量的用戶重復(fù)刷新根本不是問題。 想知道實際效果，看這里 http://blog.sina.com.cn/s/blog_466c66400100cfrj.html 1小時20億的刷新都不怕，還怕你一天10億刷新？

4.i/o優(yōu)化

其實我甚至覺得用了redis都不需要做i/o優(yōu)化了，如果用戶單據(jù)需要數(shù)據(jù)庫保存，一天200萬單嘛，搜一下 淘寶技術(shù)專家余鋒分享的qcon講座文檔，順便讀一下他歷來新浪微博分享的文字，這個需求簡直就是小兒科了。 大不了狠狠心買幾塊ssd硬盤做raid1/0，對于我這樣的窮架構(gòu)師來說，都屬于大手筆了，至于昂貴的fusion-io，我真覺得，這個場景用不著， 實在用不著。

這里關(guān)鍵點，是查詢結(jié)果的靜態(tài)化和前段緩存的利用

查詢怎么可能靜態(tài)化？

因為

1：重復(fù)查詢的頻度遠(yuǎn)遠(yuǎn)大于數(shù)據(jù)更新的頻度（即便是票數(shù)的更新，也是500:1，更不用說是有無的變化）

2：靜態(tài)化不代表不動態(tài)更新，在訂票成功后，如果發(fā)生了票數(shù)狀態(tài)的改變（是狀態(tài)改變，而不是數(shù)字改變），服務(wù)端更新或刪除該靜態(tài)結(jié)果（下一次查詢重新生成靜態(tài)結(jié)果）

至于為什么說2人2周，別搞花的，別圖好看，就把這些結(jié)構(gòu)捋清楚，代碼能有多少行？這玩意沒什么工作量。

此外，有人說，你肯定沒考慮神馬神馬神馬神馬；您說對了，我還真沒考慮這么多，畢竟鐵道部沒給我1000多萬，不過真要是給了我1000多萬，我用三天時間考慮清楚，肯定比這不到1個小時整理的東西詳細(xì)，您覺得呢，剩下一周半干活足夠完工了。

------------------------------------------------------------------------

做個簡要總結(jié)，該方案所適應(yīng)場景

1：查詢請求頻次遠(yuǎn)大于數(shù)據(jù)更新頻次。

2：所有人同一時刻查詢同一條件返回結(jié)果一致。

在二者條件滿足的情況下，查詢結(jié)果可以靜態(tài)化，靜態(tài)化不代表不動態(tài)更新

更新通過服務(wù)端的數(shù)據(jù)變化觸發(fā)，而非通過用戶請求觸發(fā)。這樣就可以保證靜態(tài)化發(fā)布和動態(tài)化更新。

靜態(tài)化發(fā)布后，利用楊建的 前端優(yōu)化技巧，設(shè)計輸出header。

根據(jù)公開數(shù)據(jù)粗略估計，10億pv請求，90%+甚至95%會落到前端緩存里，根本不會帶來服務(wù)器負(fù)載！連cdn都省下了！

明白嘛？不明白的仔細(xì)去看楊建的博客。

至于訂單系統(tǒng)，一天200萬，數(shù)據(jù)庫隨便分一下庫，還需要多少解釋？看看余鋒的微博和Qcon分享文檔，200萬請求算毛事情，不至于唧唧歪歪吧。

本文來自：曹政博客