12306，因為系統問題，成了it業界內大家茶餘飯後經常談論的話題。
先分享乙個真實故事，我同事看了12306這個**，他說，這個**做下來只要5萬，我反駁，被他嘲笑。笑話終歸笑話，沒有諷刺鐵道部，以及12306研發方的意思，我同事是實習生，他不懂12306。
近日，我們在乙個技術群裡討論了乙個開放式話題：如果我是12306架構師，該怎樣設計系統架構？
討論的內容太多，我只將討論的最終結果做些簡單梳理，並在我的blog：zouhui.blog.51cto.com上與大家分享。
架構：與其他大型**一樣，需要採用分布式設計。
前端應該有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架構師，該怎樣設計系統架構？
本文出自 「鄒輝」 部落格，請務必保留此出處
如果我是銀行App的架構師
文 明道雲創始人任向暉 我才不會每次讓使用者登入，登入資訊統統記住，3個月之內，或者主動登出之前，完全免登，開啟即用。只有在支付，轉賬動作的時候才要求生物認證或者密碼驗證。絕對不會自作聰明，設計什麼亂序數字鍵盤，更不會搞乙個所謂的安全鍵盤，讓使用者輸個密碼都要小心翼翼，安全壓根不靠這些雕蟲小技。絕對...
架構師速成8 2 架構師要懂產品
產品和架構兩個截然不同的職業。好像風馬牛不相及，事實上不是這種。產品的思想須要經過技術的手來成為現實，在成為現實之前，須要技術理解 評估 碰撞 優化 把控 驗證等等。當然架構師就承擔了這一系列技術的責任，並且在乙個產品的實現過程中，技術架構並非非常重要的，前期能夠沒有架構，簡單高速驗證，僅僅有在使用...
架構師速成8 2 架構師要懂產品
產品和架構兩個截然不同的職業，好像風馬牛不相及，其實不是這樣的。產品的思想需要經過技術的手來成為現實，在成為現實之前，需要技術理解 評估 碰撞 優化 把控 驗證等等。當然架構師就承擔了這一系列技術的責任，而且在乙個產品的實現過程中，技術架構並不是很重要的，前期可以沒有架構，簡單快速驗證，只有在使用者...