如何設計高併發高流量的12306在線票務系統
獲獎名單已公布，詳情請看：http://bbs.chinaunix.net/thread-3675185-1-1.html
「當前訪問用戶過多，請稍候重試！」「系統忙！」……類似的提示，在旅客登錄12306時屢見不鮮。12306的「不堪重負」，一方面是由於巨大的購票需求所致。鐵路部門的統計顯示，從1月5日起，12306的日均點擊量曾連續超過10億次，訪問量環比上月激增10餘倍。在我這裡我們可以以10億次/日來稍為計算下12306的併發值，10億/3600/24=0.00011570億，大約11000併發值，這個值是非常大的，對資料庫、程序、Web應用都是非常有要求的；另外，由於牽涉到票務系統的身份認證，所以安全方面也不容忽視。因此，希望我們能在這裡一起來討論下如何設計高併發高流量的12306在線票務系統的相關話題：
討論話題：
1.針對目前12306網站的瓶頸進行分析（可以是從我們自身可以獲取到的信息進行分析）。
2.如何設計和部署高併發高流量安全的在線票務系統。
3.現在有哪些比較成熟的系統或者方案。（因為12306拒絕了IBM等的成熟方案，選擇自己開發）
邀請嘉賓：
老男孩 （老男孩linux培訓）老男孩Linux實戰運維培訓中心總裁
崔曉輝（ coralzd ） 大眾網高級系統管理員
劉晗昭（wenzizone） 崑崙萬維高級架構師
胡安偉（king_819） 金游數據運維主管
劉鑫 （gray1982） 宜搜科技 高級系統運維工程師
汪洋（yanyangtian4520） HP高級.net系統架構師
余洪春（yuhongchun） 易瑞特系統架構師、《構建高可用Linux伺服器》作者
活動時間：2012.1.17-2012.2.17
活動要求：
1，針對本次話題可以提出疑問，答疑解惑。
2，分享此在線票務系統的架構經驗，案例，解決方案。
討論有獎：
活動結束后，我們會評選出三位積极參与話題討論的網友獎勵威剛 USB3.0 16GBU盤一個，對其他積极參与討論的網友（回帖有參考價值）我們將獎勵積分30分。
《解決方案》
這個話題發的有意義，參與！
《解決方案》
如此之大的併發量和PV流量，建議採用開源架構,web應用伺服器採用Nginx，資料庫採用oracle RAC集群+IBM AIX 小機。
《解決方案》
其實 這麼大的流量，需要從前端，到後台 全部都要有優化，因為任何一點小的問題*上億的PV，問題會被立刻放大
《解決方案》
前端的負載可以考慮硬體
靜態可以考慮CDN
後台的資料庫非常的頻繁，如果不考慮DB2，Oracle，只能選擇Mysql的讀寫分離
而且，資料庫前端的緩存不知道memcache集群會不會更好一些
《解決方案》
本帖最後由 gotolinux 於 2012-01-17 16:32 編輯
雖然不知道這個系統開發了多長時間，但是從應用情況來看，總體感覺還是比較倉促。
做過政府項目的都知道，這是一個十分典型的政府網站。
網站上有大量圖片，所以圖片、CSS、JS等頁面元素做好緩存是必須的。
網站上有大量的嵌套CSS，這個完全可以與頁面框架分離，緩解網站前端訪問壓力。
這些頁面元素可以根據不同城市的訪問量而使用CDN，使用CDN有個好處，部署快，穩定，可靠性高。
《解決方案》
現階段……誒……我今天都沒刷到票。
《解決方案》
說實在的，我之前沒有使用過12306，最近也是看到很多朋友放映12306不給力，我就看了下！
首先不說別的，頁面本身就沒有優化，請看下圖
初略一看，就知道有問題：把樣式嵌入在頁面中
有朋友，或許認為這不是個問題，當是這其實就加大了頁面的大小，消耗了帶寬
我們把問題在深入一點點：如果每個頁面大小70k，其中 這樣的css嵌入 假設是1k。因為每次訪問，瀏覽器需要下載頁面，那麼每次都要去下載這多餘的1k的css樣式，試想：上千萬的pv去訪問的時候，那麼產生的流量就是1k*100，000，000,
也就說明：要多消耗伺服器的這麼多網路帶寬！很要命，一點點的問題，就立刻被放大！
還不說別的
《解決方案》
定票的那幾天，一直登錄不進12306，真是悲哀，系統忙得有票都買不到。直到1.13號才登錄進去，買了2張票，不容易啊。
《解決方案》
瓶頸應該在前端過多的、無效的查詢上面。
Web伺服器按區域部署
車次信息緩存，不直接從資料庫查詢，定時刷新余票信息。
訂票請求排隊，後台按訂單次序批處理后返回結果給Web端緩存
