12306，因爲系統問題，成了IT業界內大家茶餘飯後經常談論的話題。
先分享一個真實故事，我同事看了12306這個網站，他說，這個網站做下來只要5萬，我反駁，被他嘲笑。笑話終歸笑話，沒有諷刺鐵道部，以及12306研發方的意思，我同事是實習生，他不懂12306。
近日，我們在一個技術羣裏討論了一個開放式話題：如果我是12306架構師，該怎樣設計系統架構？
討論的內容太多，我只將討論的最終結果做些簡單梳理，並在我的blog：zouhui.blog.51cto.com上與大家分享。
背景：12306，需要解決的一個核心問題是，千萬級併發的問題。同時，12306應該有自己的特色，與新浪的千萬級PV很不一樣。根絕目前12306的業務，12306對帶寬的要求其實並不大。
架構：與其他大型網站一樣，需要採用分佈式設計。
前端應該有CDN，儘量將靜態內容放到這一級，並配合其他CDN的應用模式；下一級負載均衡應該是DNS，將流量均勻分配到不同的IP；再下一級應該是LVS，將訪問請求分發到不同的物理服務器，然後再下一層纔是存儲層。採用分佈式貌似能解決12306的併發問題，爲什麼12306還是這麼慢呢？
瓶頸在哪裏？
瓶頸在數據庫。儘可能減少到達存儲層的訪問請求，這纔是12306問題的關鍵所在。
12306底層的數據庫應首選Oracle.
我們假設：單數據庫+單服務器的方式，用比較好的Unix服務器，使用OCI方式，對於非大字段(clob,blog字段)，每秒的入庫可以達到10W。
離千萬併發還差兩個數量級，因此數據庫也必須採用分佈式。
10萬的併發，WebServer有風險，實際單機apache很可能頂不住10W級併發，apache或iis很可掛了。
解決辦法：採用N個服務器M個數據庫的架構方式。
將服務器與數據庫分開，N個服務器皆可訪問M個數據庫。服務器負責處理不同物理鏈路上的請求，服務器上採用任務均衡遷移服務，同時負責與各個數據庫交互。
感性地認識這個架構，數據庫按照地區劃分，每個數據庫做備分並做warehouse（數據倉庫）將不同地域的IP分配到對應地域的服務器集羣上，比如10.0.0.x網段的集羣負責處理成都鐵路局始發的列車訂票業務，那麼這個網段的集羣只需要維護成都鐵道部轄區內的始發列車數據即可，對於IP解析與數據分發，需要重寫一個LVS分發算法。對於上海，北京，廣東這種熱門地區，需要做任務遷移處理。
按照以上的架構，大約需要400個數據庫，1000臺服務器。
最後，對於查票，定票，付寬，多學習支付寶的佳構，對於任務處理，多學習銀行的任務分發。
特別感謝本羣的：薛定諤的貓，那時花開，/bs暗夜未冥/bs，he,狼魚，濤濤，等多爲朋友對該話題的關注，並積極參與了討論。
如果你是12306架構師，該怎樣設計系統架構？