Chinaunix
標題: 如何設計高并發(fā)高流量的12306在線票務系統(tǒng) [打印本頁]
作者: 無風之谷 時間: 2012-01-17 15:39
標題: 如何設計高并發(fā)高流量的12306在線票務系統(tǒng)
獲獎名單已公布，詳情請看：http://72891.cn/thread-3675185-1-1.html
“當前訪問用戶過多，請稍候重試！”“系統(tǒng)忙！”……類似的提示，在旅客登錄12306時屢見不鮮。12306的“不堪重負”，一方面是由于巨大的購票需求所致。鐵路部門的統(tǒng)計顯示，從1月5日起，12306的日均點擊量曾連續(xù)超過10億次，訪問量環(huán)比上月激增10余倍。在我這里我們可以以10億次/日來稍為計算下12306的并發(fā)值，10億/3600/24=0.00011570億，大約11000并發(fā)值，這個值是非常大的，對數(shù)據(jù)庫、程序、Web應用都是非常有要求的；另外，由于牽涉到票務系統(tǒng)的身份認證，所以安全方面也不容忽視。因此，希望我們能在這里一起來討論下如何設計高并發(fā)高流量的12306在線票務系統(tǒng)的相關話題：
討論話題：
1.針對目前12306網(wǎng)站的瓶頸進行分析（可以是從我們自身可以獲取到的信息進行分析）。
2.如何設計和部署高并發(fā)高流量安全的在線票務系統(tǒng)。
3.現(xiàn)在有哪些比較成熟的系統(tǒng)或者方案。（因為12306拒絕了IBM等的成熟方案，選擇自己開發(fā)）
邀請嘉賓：
老男孩 （老男孩linux培訓）老男孩Linux實戰(zhàn)運維培訓中心總裁
崔曉輝（ coralzd ） 大眾網(wǎng)高級系統(tǒng)管理員
劉晗昭（wenzizone） 昆侖萬維高級架構師
胡安偉（king_819） 金游數(shù)據(jù)運維主管
劉鑫 （gray1982） 宜搜科技 高級系統(tǒng)運維工程師
汪洋（yanyangtian4520） HP高級.net系統(tǒng)架構師
余洪春（yuhongchun） 易瑞特系統(tǒng)架構師、《構建高可用Linux服務器》作者
活動時間：2012.1.17-2012.2.17
活動要求：
1，針對本次話題可以提出疑問，答疑解惑。
2，分享此在線票務系統(tǒng)的架構經(jīng)驗，案例，解決方案。
討論有獎：
活動結束后，我們會評選出三位積極參與話題討論的網(wǎng)友獎勵威剛 USB3.0 16GBU盤一個，對其他積極參與討論的網(wǎng)友（回帖有參考價值）我們將獎勵積分30分。
12121.jpg (19.58 KB, 下載次數(shù): 333)
下載附件
2012-01-17 15:39 上傳
作者: yanyangtian4502 時間: 2012-01-17 15:43
這個話題發(fā)的有意義，參與！
作者: yuhongchun 時間: 2012-01-17 15:48
提示: 作者被禁止或刪除 內(nèi)容自動屏蔽
作者: yanyangtian4502 時間: 2012-01-17 15:51
其實 這么大的流量，需要從前端，到后臺 全部都要有優(yōu)化，因為任何一點小的問題*上億的PV，問題會被立刻放大
作者: Gray1982 時間: 2012-01-17 15:57
前端的負載可以考慮硬件
靜態(tài)可以考慮CDN
后臺的數(shù)據(jù)庫非常的頻繁，如果不考慮DB2，Oracle，只能選擇Mysql的讀寫分離
而且，數(shù)據(jù)庫前端的緩存不知道m(xù)emcache集群會不會更好一些
作者: gotolinux 時間: 2012-01-17 16:03
本帖最后由 gotolinux 于 2012-01-17 16:32 編輯
雖然不知道這個系統(tǒng)開發(fā)了多長時間，但是從應用情況來看，總體感覺還是比較倉促。
做過政府項目的都知道，這是一個十分典型的政府網(wǎng)站。
網(wǎng)站上有大量圖片，所以圖片、CSS、JS等頁面元素做好緩存是必須的。
網(wǎng)站上有大量的嵌套CSS，這個完全可以與頁面框架分離，緩解網(wǎng)站前端訪問壓力。
這些頁面元素可以根據(jù)不同城市的訪問量而使用CDN，使用CDN有個好處，部署快，穩(wěn)定，可靠性高。
作者: dooros 時間: 2012-01-17 16:04
現(xiàn)階段……誒……我今天都沒刷到票。
作者: yanyangtian4502 時間: 2012-01-17 16:06
說實在的，我之前沒有使用過12306，最近也是看到很多朋友放映12306不給力，我就看了下！
首先不說別的，頁面本身就沒有優(yōu)化，請看下圖
QQ截圖未命名.png (8.39 KB, 下載次數(shù): 300)
下載附件
2012-01-17 16:00 上傳
初略一看，就知道有問題：把樣式嵌入在頁面中
有朋友，或許認為這不是個問題，當是這其實就加大了頁面的大小，消耗了帶寬
我們把問題在深入一點點：如果每個頁面大小70k，其中 這樣的css嵌入 假設是1k。因為每次訪問，瀏覽器需要下載頁面，那么每次都要去下載這多余的1k的css樣式，試想：上千萬的pv去訪問的時候，那么產(chǎn)生的流量就是1k*100，000，000,
也就說明：要多消耗服務器的這么多網(wǎng)絡帶寬！很要命，一點點的問題，就立刻被放大！
還不說別的
作者: 草上飛2008 時間: 2012-01-17 16:06
定票的那幾天，一直登錄不進12306，真是悲哀，系統(tǒng)忙得有票都買不到。直到1.13號才登錄進去，買了2張票，不容易啊。
作者: hellioncu 時間: 2012-01-17 16:07
瓶頸應該在前端過多的、無效的查詢上面。
Web服務器按區(qū)域部署
車次信息緩存，不直接從數(shù)據(jù)庫查詢，定時刷新余票信息。
訂票請求排隊，后臺按訂單次序批處理后返回結果給Web端緩存
作者: yanyangtian4502 時間: 2012-01-17 16:13
說道優(yōu)化，其實話題說不完！
當是12306扛不住了，就上了很多的服務器，也采用了群架等技術，這確實可以很快的應急！但是 站點本身的問題：程序的設計，編寫上，沒有優(yōu)化！舉個通俗的例子：對于一個病人，為了續(xù)命，我們給他開了很多的大補丸，補藥。但是病人本身的身體體質(zhì)很弱，已經(jīng)不行了！花錢大補藥可以暫時解決，但是終究還是需要病人自己鍛煉身體，增強體質(zhì)。
這里站點也是一樣的！
有時候，再稍微優(yōu)化一點點前端頁面，資源加載策略，服務器的宿主例如iis，apache等配置，可以很大程度節(jié)省經(jīng)濟成本！
如果鐵路部門認為錢不是問題，那就另當別論了！
呵呵
作者: 傷不起 時間: 2012-01-17 16:16
頂，好活動！貼近生活。
作者: 老男孩linux培訓 時間: 2012-01-17 16:19
本帖最后由 老男孩linux培訓 于 2012-01-17 17:02 編輯
這個思路非常的新穎，贊！
其實這個問題出問題的時候，我和幾個朋友探討過。
不過還真沒登陸過！
日PV10億，這個訪問量幾乎超過國內(nèi)所有單個公司網(wǎng)站的并發(fā)量了，架構設計難度是非常巨大的！
我們發(fā)現(xiàn)這個業(yè)務有幾個特點：
1）業(yè)務要求實時性高、安全性高。
2）覆蓋面積廣，請求不均勻，北上廣深圳量會更大。
3）業(yè)務不均勻，節(jié)假日并發(fā)高，平時訪問低，硬件帶寬成本難于控制。
4）web及db并發(fā)讀和寫都巨大（web,cache,db層要求都高）。
....
最難的是這么大的架構，沒有成長時間是不行的，系統(tǒng)，程序，架構各方面都難完善，所有的門戶都起碼5-10年的成長期。逐漸發(fā)展完善的。
作者: gotolinux 時間: 2012-01-17 16:37
前端的負載均衡采用Nginx/HAProxy+Keepalived
數(shù)據(jù)庫還是認為用ORACLE RAC、DB2之類的比較穩(wěn)健。
作者: 2gua 時間: 2012-01-17 16:40
Hadoop，redis啥的，整一整。
作者: yanyangtian4502 時間: 2012-01-17 16:50
其實有關nosql的一些東西，我個人發(fā)現(xiàn)：國內(nèi)炒的火，真正用的少，存在“趕時髦”的風氣
當然，個人愚見！呵呵
回復 15# 2gua
作者: gotolinux 時間: 2012-01-17 17:01
nosql還是不用的好，我認為這東西目前還不成熟，用的多的也就那幾家科技公司。
nosql也有大型故障的示例，處理起來比較棘手。
而且功能相對來說比較單一。
作者: yahoon 時間: 2012-01-17 17:19
之前那個活動結束了?
作者: yahoon 時間: 2012-01-17 17:26
并發(fā)值，10億/3600/24=0.00011570億，
這算得真沒道理...
訪問的高峰低谷都不分
作者: 無風之谷 時間: 2012-01-17 17:29
回復 18# yahoon
結束啦 正在評選獲獎網(wǎng)友啊，這兩天就公布了。
作者: yahoon 時間: 2012-01-17 17:36
老男孩linux培訓 發(fā)表于 2012-01-17 16:19 
這個思路非常的新穎，贊！
其實這個問題出問題的時候，我和幾個朋友探討過。
不過還真沒登陸過！
很中肯
作者: yahoon 時間: 2012-01-17 17:38
gotolinux 發(fā)表于 2012-01-17 17:01
nosql還是不用的好，我認為這東西目前還不成熟，用的多的也就那幾家科技公司。
nosql也有大型故障的示例， ...
對于實時性或許可以滿足,但是對于數(shù)據(jù)一致性的實現(xiàn)...
作者: sania9 時間: 2012-01-17 17:43
本帖最后由 sania9 于 2012-01-17 17:44 編輯
億級別的架構確實要考慮的太多，從編碼規(guī)范到前端緩存、db壓力，甚至帶寬等等。
不過這會的優(yōu)化可以先從業(yè)務流程上面走，分段放票什么的，造成“秒殺”型的壓力，無形中自己創(chuàng)造了很多個高峰。
既然是實名制，業(yè)務流程可以這樣（大意）：注冊后提前1個月（或更長時間）提交行程信息，針對席位、日期分批多次抽取中簽，并降低退票者的中簽概率，分散購票高峰。
作者: yahoon 時間: 2012-01-17 17:46
此業(yè)務的地域特征(北上廣,加上幾個大的中轉(zhuǎn)站), 高峰時間段(每年也就那么幾個節(jié)日), 實時要求特征明顯
個人覺得沒必要在一個機房,一組服務器來承擔全國的量
讓每個鐵路局負責自己站點的票? 用戶數(shù)據(jù)都是從統(tǒng)一的數(shù)據(jù)源的一份拷貝
就比如運營商各個地方都有分站,辦理業(yè)務只用上對應的分站,而不是一個portal
而且數(shù)據(jù)查詢還是可以優(yōu)化的,并不是每次點擊查詢都要去數(shù)據(jù)庫
現(xiàn)在最突出的是查到了有票,但是提交不進去,因為全國的寫操作都對一個庫在操作
可想而知了
作者: gotolinux 時間: 2012-01-17 17:48
回復 19# yahoon
其實訪問量最大的就是發(fā)票前后的那幾個小時。
作者: gotolinux 時間: 2012-01-17 17:50
yahoon 發(fā)表于 2012-01-17 17:46
此業(yè)務的地域特征(北上廣,加上幾個大的中轉(zhuǎn)站), 高峰時間段(每年也就那么幾個節(jié)日), 實時要求特征明顯
個 ...
數(shù)據(jù)庫的操作應該是一個主數(shù)據(jù)庫多個從數(shù)據(jù)庫，讀寫分離的方式。
作者: yuhongchun 時間: 2012-01-17 17:52
提示: 作者被禁止或刪除 內(nèi)容自動屏蔽
作者: yahoon 時間: 2012-01-17 17:53
另 關于投入的問題, 僅僅為了應付有限的幾個熱點時間段,就采購大量的服務器和帶寬放在那,確實是有點浪費資源和帶寬.
大家有啥想法,平時出租計算資源給啥統(tǒng)計局或者氣象局之類的? 哈哈
作者: Gray1982 時間: 2012-01-17 17:55
yahoon 發(fā)表于 2012-01-17 17:46
此業(yè)務的地域特征(北上廣,加上幾個大的中轉(zhuǎn)站), 高峰時間段(每年也就那么幾個節(jié)日), 實時要求特征明顯
個 ...
數(shù)據(jù)庫要改的N多，最主要的不能是總直接查詢庫，要有緩存；讀寫還得分離，庫、表的設計也要跟行上，字段、值都是很大的，不知道有沒有專業(yè)的人搞過。
誰把那個庫的數(shù)據(jù)來展示一下:wink:
作者: yahoon 時間: 2012-01-17 17:56
yuhongchun 發(fā)表于 2012-01-17 17:52
這只是一個提供理論值而矣
我覺得最高并發(fā)是遠高于這個數(shù)的 至少從24點到7點半之前,感覺訪問的量不會特別大的
作者: yahoon 時間: 2012-01-17 17:57
Gray1982 發(fā)表于 2012-01-17 17:55
數(shù)據(jù)庫要改的N多，最主要的不能是總直接查詢庫，要有緩存；讀寫還得分離，庫、表的設計也要跟行上，字段 ...
據(jù)我實際使用發(fā)現(xiàn),現(xiàn)在他查的方式就是緩存
作者: yahoon 時間: 2012-01-17 18:05
sania9 發(fā)表于 2012-01-17 17:43
億級別的架構確實要考慮的太多，從編碼規(guī)范到前端緩存、db壓力，甚至帶寬等等。
不過這會的優(yōu)化可以先從業(yè) ...
中簽這個有點意思
感覺跟北京汽車搖號一樣
我頂一下
同樣是拼人品和運氣,搖號總比這樣哄搶好.
另外,必須是第三方機構負責搖號
作者: lltlk 時間: 2012-01-17 18:11
頭兩天，是網(wǎng)站打不開，如yanyangtian4502所說，應該要優(yōu)化web代碼。CDN是必須的，事實上也是上了CDN。
用戶登錄，可以對用戶進行分區(qū)，認證模塊用內(nèi)存+文件的cache。用戶登錄時利用索引路由到分區(qū)的認證模塊。session可以用專門的session server管理，而不是web app管理。
上億注冊用戶，每天百萬級別的活躍用戶，目前沒大問題，也可隨意擴容。
個人見解。
作者: hjk857 時間: 2012-01-17 18:25
政府網(wǎng)站一向既難看又難用，一點都不顧及用戶的感受，費用支出卻是最高的。
非常贊成基礎架構沒做好的說法，基礎沒弄好其它的都白扯。
作者: gotolinux 時間: 2012-01-17 19:04
我認為這篇討論大部分地方可以參考：http://72891.cn/thread-3626937-7-1.html
主要值得提出來的地方，我認為有以下幾點：
1.流量分析，其實這個在應用上架前就能做好，鐵道部可以從以往的人口流量映射訪問流量。當然這樣會有一定的偏差，同時也涉及到地域性流動人口的知識架構。
不過現(xiàn)階段的工作是改進，對于已經(jīng)運行這么長時間的系統(tǒng)，流量的掌握應該已經(jīng)到了比較精確的地步。
下一步就是cache服務器的部署、CDN的選擇、各種負載均衡系統(tǒng)的選擇等等問題，這些都可以參照以前的討論《千萬級pv高性能高并發(fā)網(wǎng)站架構與設計交流探討帖》http://72891.cn/thread-3626937-7-1.html。
2.應用本身的架構，也就是此次討論的主旨——在線票務系統(tǒng)的架構。
首先，就是開發(fā)語言的選擇，從頁面上來看，應該是java。
其次，開發(fā)框架的選擇。
再次，腳本服務器的選擇，從曾經(jīng)出錯的信息上看有網(wǎng)友說是JBoss。
換架構可以說是不可能的是，只能優(yōu)化、優(yōu)化、再優(yōu)化。
3.應用的部署
扯開分布式部署、負載均衡等技術不說。我認為，這個大規(guī)模的應用完全可以采取省級部署的方式，分別用二級域名來引導進入不同地域進行購票。比如：廣東就用gd.12306.com，湖南就用hn.12306.com，把整個系統(tǒng)劃分為多個小系統(tǒng)，并在后端集中。
4.其他方面
（1）系統(tǒng)忙會造成用戶強行退出，用戶不得不多次登陸，這也增加了系統(tǒng)的負載，同時也成就了大量的刷票軟件的存在。
（2）支付方面，需要在一定時間內(nèi)完成付款，否則訂單取消。其實可以做個充值功能，用戶先查好所需車票的金額，沖入賬戶，如購票失敗則可隨時申請退款。
（3）數(shù)據(jù)庫方面。12306的數(shù)據(jù)庫主要涉及兩方面：用戶信息和票務信息。這兩方面的數(shù)據(jù)分離我認為是必須的，即減輕系統(tǒng)負載，也增加系統(tǒng)相應。讀寫分離、cache、負載就不多說了。
作者: gotolinux 時間: 2012-01-17 19:20
曾經(jīng)接觸過一個政府的項目，要求由一國產(chǎn)的中間件換成websphere，給了一個月的時間，硬是沒完成，最后也只能將就著用。
政府項目有其特殊性，有其特殊的招標渠道、有指定的投標商。
其實這些不可避免的“人文因素”往往會照成系統(tǒng)的“弱應用性”。
作者: kns1024wh 時間: 2012-01-17 19:28
回復 1# 無風之谷
"是否是無證程序員"
作者: 老男孩linux培訓 時間: 2012-01-17 19:42
本帖最后由 老男孩linux培訓 于 2012-01-17 20:43 編輯
回復 36# gotolinux
我認為這篇討論大部分地方可以參考：http://72891.cn/thread-3626937-7-1.html
主要值得提出來的地方，我認為有以下幾點：
1.流量分析，其實這個在應用上架前就能做好，鐵道部可以從以往的人口流量映射訪問流量。當然這樣會有一定的偏差，同時也涉及到地域性流動人口的知識架構。
不過現(xiàn)階段的工作是改進，對于已經(jīng)運行這么長時間的系統(tǒng)，流量的掌握應該已經(jīng)到了比較精確的地步。
下一步就是cache服務器的部署、CDN的選擇、各種負載均衡系統(tǒng)的選擇等等問題，這些都可以參照以前的討論《千萬級pv高性能高并發(fā)網(wǎng)站架構與設計交流探討帖》http://72891.cn/thread-3626937-7-1.html。
2.應用本身的架構，也就是此次討論的主旨——在線票務系統(tǒng)的架構。
首先，就是開發(fā)語言的選擇，從頁面上來看，應該是java。
其次，開發(fā)框架的選擇。
再次，腳本服務器的選擇，從曾經(jīng)出錯的信息上看有網(wǎng)友說是JBoss。
換架構可以說是不可能的是，只能優(yōu)化、優(yōu)化、再優(yōu)化。
3.應用的部署
扯開分布式部署、負載均衡等技術不說。我認為，這個大規(guī)模的應用完全可以采取省級部署的方式，分別用二級域名來引導進入不同地域進行購票。比如：廣東就用gd.12306.com，湖南就用hn.12306.com，把整個系統(tǒng)劃分為多個小系統(tǒng)，并在后端集中。
4.其他方面
（1）系統(tǒng)忙會造成用戶強行退出，用戶不得不多次登陸，這也增加了系統(tǒng)的負載，同時也成就了大量的刷票軟件的存在。
（2）支付方面，需要在一定時間內(nèi)完成付款，否則訂單取消。其實可以做個充值功能，用戶先查好所需車票的金額，沖入賬戶，如購票失敗則可隨時申請退款。
（3）數(shù)據(jù)庫方面。12306的數(shù)據(jù)庫主要涉及兩方面：用戶信息和票務信息。這兩方面的數(shù)據(jù)分離我認為是必須的，即減輕系統(tǒng)負載，也增加系統(tǒng)相應。讀寫分離、cache、負載就不多說了。
=======================
老男孩評：考慮的很多，贊！
能事先分析需求，并按地域分域名思路很不錯，不過這個不同地點購票可能難做，這個要和現(xiàn)有的不同地區(qū)的鐵路售票系統(tǒng)節(jié)點對接（資金太大），
找?guī)讉�核心骨干的售票系統(tǒng)對接就好。
之所以堵，這個和對接的鐵路售票系統(tǒng) 的節(jié)點多少及鐵路售票系統(tǒng)整個吞吐有關。網(wǎng)絡除了并發(fā)大，還要連續(xù)刷新。是平時各個點售票并發(fā)的好多倍。
比如平時北京也就上千個售票點，大家排隊就是隊列。�！，F(xiàn)在在這個隊列沒了，海量的人直接打開頁面刷。并發(fā)頁面訪問10幾萬都有可能。
考慮到鐵路的實際售票系統(tǒng)的吞吐情況，提交數(shù)據(jù) 使用隊列 可能是必須的，否則，就得改造傳統(tǒng)的售票系統(tǒng)了。
除了和售票系統(tǒng)對接交換數(shù)據(jù)外，網(wǎng)站本身也需要一個分布式的數(shù)據(jù)庫。
先寫這么多。
扔個分布式票務架構模型圖：
Snap8.jpg (52.71 KB, 下載次數(shù): 104)
下載附件
2012-01-17 20:43 上傳
作者: kns1024wh 時間: 2012-01-17 19:43
回復 3# yuhongchun
如果是j2ee的應用，很多項目的實施中是不會考慮前端的web應用服務器采用Nginx調(diào)度，多數(shù)是直接用j2ee的應用平臺的。而且此類大型系統(tǒng)比人是要用到小雞的，目前國內(nèi)的行業(yè)基本上是如此。開源技術多數(shù)是在互聯(lián)網(wǎng)領域應用很多的。
作者: kns1024wh 時間: 2012-01-17 19:47
yanyangtian4502 發(fā)表于 2012-01-17 16:06
說實在的，我之前沒有使用過12306，最近也是看到很多朋友放映12306不給力，我就看了下！
首先不說別的，頁 ...
這個就是 做互聯(lián)網(wǎng)運維的兄弟 看到的真實的狀況，在那些開發(fā)此類系統(tǒng)的人員來說，是不會考慮這些細節(jié)問題的。
一個好的建議，在這個討論結束的時候，以CU社區(qū)的名義出提出一個針對性的優(yōu)化建議 ，不過想想也很遙遠，有多少幾率會被接受。
在此討論此問題就是來思考好互聯(lián)網(wǎng)我們熟悉的領域中的運維該如何優(yōu)化提升性能。
這個討論話題就不咋得體 ，如何基于開源架構設計一套在線票務系統(tǒng) 應該比較的貼切，可以根據(jù)目前的 春運來做討論
作者: kns1024wh 時間: 2012-01-17 19:48
回復 9# 草上飛2008
黃牛應該 比較方便 呵呵
作者: chenyx 時間: 2012-01-17 19:50
回復 4# yanyangtian4502
嗯,同意,這么大的訪問量,任何一個小的失誤,就會被幾何級的放大.
作者: kns1024wh 時間: 2012-01-17 19:50
老男孩linux培訓 發(fā)表于 2012-01-17 16:19
這個思路非常的新穎，贊！
其實這個問題出問題的時候，我和幾個朋友探討過。
不過還真沒登陸過！
業(yè)務系統(tǒng)的背景 需求不同 這個只是針對性的考慮 ，如果說業(yè)務量大 銀聯(lián)的系統(tǒng)交易量更加大
作者: chenyx 時間: 2012-01-17 19:54
回復 45# kns1024wh
銀聯(lián)的交易與12306的交易完全不是一個層面的東西.銀聯(lián)的交易,對象是確定的,比如,刷卡,查詢的對象僅僅是這個賬戶本身而已.
而12306的交易,在訂票之前,要查詢很多次,復雜度要比單筆交易簡單多了.
另外,銀聯(lián)可以說是分布式的交易,12306這次暴露的問題是集中交易造成的帶寬以及服務器資源的不足.
作者: chenyx 時間: 2012-01-17 19:59
12306問題的根結我覺得在于沒有分布式的處理,試想,如果象銀聯(lián)那樣,每個省做一個服務群,這樣就會把現(xiàn)在的集中訪問分配到不同的服務器上,這樣,比單純的在中央增加集群的機器數(shù)量的做法,能緩解不少.
作者: gotolinux 時間: 2012-01-17 20:00
回復 40# kns1024wh
我始終認為J2EE是個很“重”的應用，想要從開發(fā)層面讓整個應用“輕”起來不太可能，只能靠后端支持。
作者: chenyx 時間: 2012-01-17 20:02
回復 8# yanyangtian4502
這樣的網(wǎng)頁編寫確實和拙略,至少應該少用行內(nèi)的style定義,直接定義一個css文檔,節(jié)省流量的同時,對服務器的硬盤負載也會有幫助.
另外,一般瀏覽器都會緩存網(wǎng)頁的,css文件也能有效減少客戶端對服務器的請求,對帶寬的占用也會少很多
作者: chenyx 時間: 2012-01-17 20:06
從優(yōu)化的角度,應該著重處理后端數(shù)據(jù)庫的壓力,對數(shù)據(jù)流程進行優(yōu)化,減少不必要的查詢.
以前看過一個分析php性能的文章,大部分時間,php都在等待中,等待后臺的數(shù)據(jù)庫返回查詢的結果.
后臺數(shù)據(jù)節(jié)省1s,對于10億pv的訪問來說,也能放大優(yōu)化的效果.
作者: chenyx 時間: 2012-01-17 20:13
老男孩linux培訓 發(fā)表于 2012-01-17 16:19
這個思路非常的新穎，贊！
其實這個問題出問題的時候，我和幾個朋友探討過。
不過還真沒登陸過！
這個是沒辦法的事情,我們有我們的國情,不可能把春運的流量分攤到別的時間去處理.春運結束之后,可能之前的架構應付也綽綽有余.
就是平時沒事情干,到春運的時候又忙不過來.
如何增加系統(tǒng)的彈性,也就是說,平時用很少的資源就可以滿足需要,到高峰期,又能通過水平擴展,通過簡單的增加資源的方法,就能解決問題.
我想,解決了上述問題的話,谷歌/百度也會汗顏的.
作者: chenyx 時間: 2012-01-17 20:16
回復 39# 老男孩linux培訓
嗯,最簡單的辦法就是放權,把過分集中的請求分發(fā)到各個省去,這樣,就能緩解帶寬過載的問題.
作者: chenyx 時間: 2012-01-17 20:17
yanyangtian4502 發(fā)表于 2012-01-17 16:13
說道優(yōu)化，其實話題說不完！
當是12306扛不住了，就上了很多的服務器，也采用了群架等技術，這確實可以很快 ...
據(jù)網(wǎng)上的報道,鐵道部還是缺錢的,并且缺口還很大.
作者: gotolinux 時間: 2012-01-17 20:45
回復 31# yahoon
其實高并發(fā)的來源還是他自己的定時放票，只有這么幾個時段，買不到票的當然往死里刷了。
作者: chenyx 時間: 2012-01-17 21:06
本帖最后由 chenyx 于 2012-01-17 21:07 編輯
gotolinux 發(fā)表于 2012-01-17 20:45
回復 31# yahoon
同意,認為造成流量集中.流程還是有很大改進空間的
作者: 村口老柳樹 時間: 2012-01-17 22:50
覺得后臺的數(shù)據(jù)庫沒有把各個車次分開，或者說訂單沒有分開，導致太多的系統(tǒng)資源爭用，所以在點擊訂票的時候一直訂不上
作者: yanyangtian4502 時間: 2012-01-17 23:01
本帖最后由 yanyangtian4502 于 2012-01-17 23:07 編輯
基本可以從以下幾個方面進行考慮：
1.如何使得服務器更快的處理請求
2.如何使得響應更快的發(fā)送到客戶端
3 減少不必要的請求
首先我們從站點本身的設計來看：
1.如何使得服務器更快的處理請求：那么就要充分的利用服務器的每一點資源：內(nèi)存，CPU，緩存，線程，數(shù)據(jù)庫
對于內(nèi)存：因為程序是用Java寫的，那么就需要注意：
a. java對象的回收與釋放，不要認為這不是問題,一般站點，常常有很多的對象提供功能，加上10000個對象，不多吧，現(xiàn)在假設，每次請求，都需要產(chǎn)生1000個新的臨時對象處理這個請求（其余的9000個對象是所有請求都要使用的），假設每個對象占1k，1000個就約等于1M，也就說，每次請求，需要產(chǎn)生1M的對象內(nèi)存，如果訪問量就是千萬級別，想想看，嚇人吧。很多人認為java有垃圾回收機制，不用管，能不管嗎？
b. 注意系統(tǒng)資源的使用。站點免不了要去操作文件，線程等系統(tǒng)的一些資源，那么，使用完之后，要注意釋放，一是為了避免其他請求等待，也是使得內(nèi)存快速回收。
c. 在使用cookie和session之前，要算筆賬：性能和安全的。如果真要使用session，就要考慮很多的問題，舉個數(shù)據(jù)，大家就明白了：一般session的有效時間是20mins（可以自己設置了），假設每個用戶在站點停留10min，不過分吧，買票嘛，總的看看，輸入信息吧。那么用戶的session存活期就是30min了。
假設每秒100個請求訪問站點，而每個用戶發(fā)送5個請求，這個時候，站點就是100/5，每秒20個用戶訪問站點。假設那么，在session存活期內(nèi)（30min），站點的session個數(shù)就是：60*30*20=36000個，想想看，即使每session只保存1k的數(shù)據(jù)，也是36M，這還是只有100請求的情況，如果請求是千萬級別，想想看。
對于CPU：不要認為服務器CPU牛X，就隨便搞。注意的請求很多：
a. 考慮多線程的使用，不要沒事就開線程。線程開啟需要CPU分配，調(diào)度，管理啊！
b.不要沒事就try..catch到處搞。異常捕捉需要遍歷調(diào)用堆棧的，那個效率~~~。
c.加密解密要注意個度，因為這些算法消耗內(nèi)存和CPU，也需要CPU大量的計算
d.不要頻繁讀模板，該緩存的就緩，不要總是拼接，替換，要注意緩沖池的使用。
e.正則表達式要注意使用，要使用編譯后的，最好是編譯后緩存起來，下次直接使用。正則表達式也是一種語言，需要分法，詞法分析，很復雜的，懂編譯原理應該明白這個道理。
f. 注意CPU喜歡減法操作，考慮用位操作替換浮點操作，不要認為是小事，千萬級別問題就大了。
...
然后我們從運維方面看：
寫累了，歇一會在寫
隨便寫寫，一大堆。
作者: yanyangtian4502 時間: 2012-01-17 23:05
其實仔細想想，編寫程序很容易！
但是編程好的程序，真是不容易！
考慮的問題，涉及到的知識廣度，深度
作者: gotolinux 時間: 2012-01-17 23:48
yanyangtian4502 發(fā)表于 2012-01-17 23:01
基本可以從以下幾個方面進行考慮：
1.如何使得服務器更快的處理請求
2.如何使得響應更快的發(fā)送到客戶端
非常贊同�，F(xiàn)在的程序員跟C時代的程序員簡直沒法比。以為有了垃圾回收就不用管內(nèi)存了，太注重應用本身的功能性，而忽視了程序的細節(jié)處理、資源利用。
作者: gotolinux 時間: 2012-01-18 00:02
村口老柳樹 發(fā)表于 2012-01-17 22:50
覺得后臺的數(shù)據(jù)庫沒有把各個車次分開，或者說訂單沒有分開，導致太多的系統(tǒng)資源爭用，所以在點擊訂票的時候 ...
嗯，這個也不錯。還有一點，很多購票者都是臨時注冊，臨時購票，而且會多次注冊，利用多個ID來搶票。這一方面也會增加系統(tǒng)的負載。
用戶注冊和用戶購票可以進行應用分割，后端數(shù)據(jù)同步。這就是我前面提到的用戶信息（數(shù)據(jù)庫）和票務信息（數(shù)據(jù)庫）分離。
作者: 阿輝 時間: 2012-01-18 09:18
yanyangtian4502 發(fā)表于 2012-01-17 16:06
說實在的，我之前沒有使用過12306，最近也是看到很多朋友放映12306不給力，我就看了下！
首先不說別的，頁 ...
這個是問題，但不是目前的瓶頸，因為它也是有做cdn的，目前的瓶頸不在這塊，打開1230**的首頁還是很快的，只是打開動態(tài)頁面時才慢，明顯是服務器問題。
當然他們做cdn也有問題，動態(tài)內(nèi)容也走cdn了，并不是一個很好的方式，個人認為動態(tài)內(nèi)容也走cdn會導致更慢，雖然cdn廠商不這樣認為。
作者: sania9 時間: 2012-01-18 09:19
頂一記，分省部屬分流確實不錯！
作者: rmn190 時間: 2012-01-18 09:26
hellioncu 發(fā)表于 2012-01-17 16:07
瓶頸應該在前端過多的、無效的查詢上面。
Web服務器按區(qū)域部署
越買不到票， 越是刷無效的請求。
應該說， 這個不是問題本質(zhì)，但是問題的最表面。
作者: renxiao2003 時間: 2012-01-18 09:31
本帖最后由 renxiao2003 于 2012-01-20 22:45 編輯
臨近春節(jié)了，在各大網(wǎng)站上火爆的不是春節(jié)怎么過，而是春節(jié)怎么“回”，一張小小的火車票，成為了中國人最傷不起的焦點話題�！靶』镞B續(xù)3天守電腦前搶火車票，稱‘想砸電腦’”、“訂票網(wǎng)刷500次才能買一張票”。據(jù)說鐵道部官方訂票網(wǎng)站www.1230**每天點擊量超過14億次。身為苦逼的ＩＴ民工，我也是當前搶票一族。在經(jīng)歷了整整一天的刷票無果之后，我那叫一個——感慨萬千。
首先掰掰現(xiàn)在流行的各大自動購票軟件，說白了就是原來需要人手動干的事兒，現(xiàn)在用程序來完成，不停幫你重復。沒什么太深奧的地方，雖說人再快也趕不上機器，但是大家都開始用了也就起不到什么作用了�；驹砭褪怯贸绦蜃ト�.cn頁面，將用戶名密碼填寫后，程序自動登陸，如果登陸不上，自動重試，直到登陸成功。查詢和訂票過程也是一樣，12306上現(xiàn)在用算術來驗證，也都可以破解的。這個東西電商上現(xiàn)在賣家很多，價格也不高，實在走投無路的兄弟可以一試。但是要小心他盜取你的帳戶密碼。
在用機器刷票的無聊期，我上微博去逛了一圈。也看看大家對春運都吐了什么槽。偶然發(fā)現(xiàn)一篇微博，覺得有點意思，拿出來分享下：
這個倒是啟發(fā)了我，如果架構允許的話，火車購票網(wǎng)還真的可以并且非常適合用云計算搭建。這個網(wǎng)站去年6月就開始使用了，但是為啥一直沒發(fā)現(xiàn)問題？原因很簡單，以前沒有全國人民一起搶票的陣勢！正是一時間集中的瀏覽量和交易量，導致服務器負載過大，不能承受業(yè)務峰值，而搭建網(wǎng)站的傳統(tǒng)服務器無法完成快速擴展，難以滿足目前的業(yè)務需求。
火車票其實也算典型的季節(jié)性熱銷品，五一、十一、春運的時候一票難求，而平日一些動車部分車廂也會空空蕩蕩。以前大家都扛著鋪蓋排通宵，所有車站都可以買票。今年鼓勵網(wǎng)絡售票，只有一個網(wǎng)站入口，上億群眾一起往里沖，服務器沒癱瘓就是不幸中的萬幸。傳統(tǒng)服務器模式的一大弊端就是擴展非常緩慢，如果要滿足春運這一個月的需求，必須事先準備大量的服務器，這不僅需要巨大的硬件成本支出，而且這些服務器在平時根本派不上用場，處于閑置狀態(tài)，高峰來了臨時準備來不及，處理的時候基本就是廢鐵一堆，一文不值。而云計算具有快速彈性擴展的特點，當業(yè)務高峰來臨的時候，可以在很短的時間內(nèi)部署完成云主機，而當高峰過后，立即刪除。據(jù)我所知，國內(nèi)有些云計算，如盛大云，已經(jīng)精確到小時計費了，真正按需使用，可以節(jié)省不小的成本。雖說鐵道部不差錢，但是節(jié)省下來的費用，希望也能多修幾條鐵路，開通一些臨客，盡早讓“春運”這一具有中國特色的名詞成為歷史。
快到春節(jié)了，分外想家，和父母一起親親熱熱地吃頓年夜飯，看看春晚，放放鞭炮，這一年的辛苦就仿佛得到了慰藉。我想所有有興趣看這個帖子的人都有同樣的感受。去年一年，國內(nèi)的云計算取得了非常快速的發(fā)展，盛大云、阿里云等等都在化云為雨，多了不少成功的云計算實踐案例。此刻，寫下這個帖子，只是希望有一天，能夠依靠技術的力量，讓每個離家在外的中國人都能坐上回家的列車。
作者: gotolinux 時間: 2012-01-18 09:32
阿輝 發(fā)表于 2012-01-18 09:18
這個是問題，但不是目前的瓶頸，因為它也是有做cdn的，目前的瓶頸不在這塊，打開1230**的首頁還是很快的 ...
我也贊同，其實CDN，負載均衡本身，他們肯定有做，只是達不到理想的效果。
其實問題本身可能是應用的問題，如何提高應用的內(nèi)部響應，對應用進行合理分割，減少應用內(nèi)部負載才是解決問題的關鍵。
作者: 阿輝 時間: 2012-01-18 09:33
老男孩linux培訓 發(fā)表于 2012-01-17 16:19
這個思路非常的新穎，贊！
其實這個問題出問題的時候，我和幾個朋友探討過。
不過還真沒登陸過！
同意。
首先必需說目前的www.1230**做得太爛，他們完全可以做得更好再拿出來，不要讓人覺得像個小學生或新手寫的網(wǎng)站。
其次就是高并發(fā)的問題并不像大家說的那么簡單。有下面幾個原因：
1.凡是涉及到錢的場合，很多nosql的東西可能并不適用。
2.一般網(wǎng)站用的分庫分表技術也不一定適合
3.因為同時也有電話訂票。據(jù)我估計他們應該是有一個中心服務器，提供接口給電話和網(wǎng)站服務來查詢和訂票�？隙ú皇侵苯硬僮鱀B，應該是通過一個類似訂票接口（可以理解成中間件）來操作的。
最后我認為，他們的瓶頸在于數(shù)據(jù)庫，他們需要優(yōu)化的是他們的中心服務器和數(shù)據(jù)庫，如訂票接口和設計架構。但是我們都不了解現(xiàn)在的架構，就不亂說了。
作者: gotolinux 時間: 2012-01-18 09:48
網(wǎng)上有個訂票流程，大家可以看看。
12306網(wǎng)站訂票流程1.png (47.35 KB, 下載次數(shù): 68)
下載附件
2012-01-18 09:48 上傳
作者: tochu 時間: 2012-01-18 10:14
這種量級,當然應該使用memcache，采用oracle, db2或者PostgreSQL其實并不是太重要，有紀錄的處理能力，在一個銀行應用里面，PostgreSQL每秒能處理18000個事務，所以重要的是系統(tǒng)的設計跟做設計的人
帖子開頭計算的每秒事務量是一萬一，都太樂觀了，因為考慮的一天24小時是平均的，平滑的，如果考慮到峰值，比這個量還要大許多。
哥最厭惡的就是動動嘴的專家，說的比唱的好聽，一做事情，就那個熊樣……
作者: tochu 時間: 2012-01-18 10:27
回復 67# 阿輝
不能用nosql這種數(shù)據(jù)庫不是絕對的，傳統(tǒng)的數(shù)據(jù)庫重要的一個特性就是保證ACID, 完全可以把ACID做在數(shù)據(jù)庫之上，應用邏輯內(nèi)，建議看看那本書 <事物處理>
作者: yuhongchun 時間: 2012-01-18 11:03
提示: 作者被禁止或刪除 內(nèi)容自動屏蔽
作者: Gray1982 時間: 2012-01-18 11:21
都說的那么多，老男孩的一個幾本結構也給出來了
都考慮的是前面CDN，WEB代碼，后臺數(shù)據(jù)庫等
有沒有想過隊列的問題呢？WEB分流，數(shù)據(jù)庫分離，隊列的分布式呢··········
作者: wpfchinaunix 時間: 2012-01-18 11:35
應對十幾億次的日點擊量，至少要20萬臺服務器，目前12306的服務器太少了
作者: 無牙 時間: 2012-01-18 11:45
體制決定的，不是什么系統(tǒng)上的問題。
作者: 無牙 時間: 2012-01-18 11:46
網(wǎng)上購票設計不是我們想象的這么簡單。
作者: 無牙 時間: 2012-01-18 11:49
客運火車分局內(nèi)和跨局的，如果系統(tǒng)按地區(qū)分，你買票的時候到底應該登那個網(wǎng)站？
作者: gotolinux 時間: 2012-01-18 11:58
wpfchinaunix 發(fā)表于 2012-01-18 11:35
應對十幾億次的日點擊量，至少要20萬臺服務器，目前12306的服務器太少了
其實主要是突發(fā)高流量的應付，也就是放票的那幾個時段，當然也就是春運以及節(jié)假日，平日的流量基本都比較小。
這也牽扯到運營成本了。
作者: KevinLee39 時間: 2012-01-18 14:09
給google交點錢，用GAE算了。
作者: gotolinux 時間: 2012-01-18 14:23
KevinLee39 發(fā)表于 2012-01-18 14:09
給google交點錢，用GAE算了。
GAE 就不現(xiàn)實了，前面有G_F_W擋著，后面的開發(fā)也有很大的限制。
作者: 無牙 時間: 2012-01-18 15:11
用GAE一點都不現(xiàn)實。
作者: kns1024wh 時間: 2012-01-18 15:11
KevinLee39 發(fā)表于 2012-01-18 14:09
給google交點錢，用GAE算了。
GAE 應該不適合解決此類問題的 而且用戶信息的認證似乎也無法實現(xiàn)
作者: 無牙 時間: 2012-01-18 15:29
Gray1982 發(fā)表于 2012-01-17 15:57
前端的負載可以考慮硬件
靜態(tài)可以考慮CDN
后臺的數(shù)據(jù)庫非常的頻繁，如果不考慮DB2，Oracle，只能選擇Mysq ...
后臺現(xiàn)在用的就是Oracle RAC, 其實數(shù)據(jù)庫的并不忙。
網(wǎng)絡資源應該還是12306的主要瓶頸。
作者: 無牙 時間: 2012-01-18 15:55
我們可以先從網(wǎng)上訂票的流程分析一下。
網(wǎng)上訂票至少會有如下幾步：
1.網(wǎng)站登入
2.查詢余票
3.訂票
4.提供乘車人信息
5.提交訂單
6.支付票款
7.等待銀行返回信息
8.確認訂票成功
從這個流程上看，12306至少要做這個么幾個優(yōu)化：
1.查詢和訂票分開；這個分開是指不要訪問同樣的庫，采用讀寫分離的方式。
2.付款和訂票分開；付款不要占用訂票的資源，特別是網(wǎng)絡資源。
3.訂單查詢也要和訂票系統(tǒng)分開；
4.避免同一IP，同一個時間開多個session;
我不是做網(wǎng)站開發(fā)的，能想到的就是這些。就當拋磚引玉了，歡迎拍磚！
作者: 無牙 時間: 2012-01-18 16:04
從我對客票系統(tǒng)的理解，分票是比較麻煩的，因為火車票和飛機票不同的地方就是，火車80%以上的車次都是有中間停靠站的，這就需要為這些站預留車票。 票分的不好就會造成啟始站的上座率。
作者: cyclonical 時間: 2012-01-18 16:07
登陸首頁，速度還是可以的，沒有一次顯示無法打開頁面，應該已經(jīng)使用過成熟的CDN產(chǎn)品
用戶登陸不上或者報錯還應該是并發(fā)登陸的問題，解決辦法我還是比較贊同廣告殺手的意見！
作者: gotolinux 時間: 2012-01-18 16:13
現(xiàn)在的問題是，我們不知道現(xiàn)有系統(tǒng)的架構，只能從自己認知的角度去出發(fā)。
雖說前期調(diào)研準備很重要，但是就目前的情況還是分析問題更有效率。
作者: zhanlongzaiye 時間: 2012-01-18 16:15
個人覺得，把頁面中要提交的元素精簡到最低，比如關鍵字能簡單就簡單，少一個字節(jié)是一個自己，如password，改成pd或者其他的，等等
作者: 無牙 時間: 2012-01-18 16:17
cyclonical 發(fā)表于 2012-01-18 16:07
登陸首頁，速度還是可以的，沒有一次顯示無法打開頁面，應該已經(jīng)使用過成熟的CDN產(chǎn)品
用戶登陸不上或者報 ...
首頁登錄非�？�，這已經(jīng)說明帶寬已經(jīng)擴了，去年年初的時候（2011年）還經(jīng)常會遇到首頁訪問非常慢的情況。
作者: zhanlongzaiye 時間: 2012-01-18 16:24
查詢的分流機制要做到，省內(nèi)的，跨省的等等，接到查詢請求后，用不同的機器來做處理，一個查詢流程可以分成很多步驟，把每一步都用不同的機器來處理，這樣會使一個查詢流程變的相對復雜，但能讓大量的查詢流程變的順暢。
作者: gotolinux 時間: 2012-01-18 16:25
zhanlongzaiye 發(fā)表于 2012-01-18 16:15
個人覺得，把頁面中要提交的元素精簡到最低，比如關鍵字能簡單就簡單，少一個字節(jié)是一個自己，如password， ...
前面有朋友已經(jīng)提出了，頁面的載入速度還不錯，出問題的主要是后端的處理。
關于關鍵字的優(yōu)化，我想在出問題后這方面應該他們也有考慮。
作者: Gray1982 時間: 2012-01-18 16:34
無牙 發(fā)表于 2012-01-18 15:55
我們可以先從網(wǎng)上訂票的流程分析一下。
網(wǎng)上訂票至少會有如下幾步：
這些差不多都是只要是帶寬，網(wǎng)線，交換機等都能解決的
主要還是在看架構上的一個設計，如果涉及到細節(jié)，不是說用了什么就可以，而是說怎么用，怎么調(diào)才可以，像你說的分庫，分表，讀寫分離，表引擎，字段等
IP限制，session限制，時間失效性，這也都是需要設定一個會更的值
作者: gotolinux 時間: 2012-01-18 16:34
除了前面說的，有朋友也指出了隊列的問題，我認為隊列處理也是一個非常重要的問題。
在線訂票和在窗口買票的原理、過程都一樣，就是排隊。如何處理好這個隊列，十分關鍵。
作者: gotolinux 時間: 2012-01-18 16:39
Gray1982 發(fā)表于 2012-01-18 16:34
這些差不多都是只要是帶寬，網(wǎng)線，交換機等都能解決的
主要還是在看架構上的一個設計，如果涉及到細節(jié) ...
目前，系統(tǒng)在出問題以后采用的解決方案就是硬件堆積，同樣問題沒有得到解決�？梢妴栴}的根本是軟件系統(tǒng)的架構。
作者: kingstar 時間: 2012-01-18 16:40
看來各位忽視了一個嚴重的問題：
本人對現(xiàn)狀非常滿意：
------------------------------
原因如下：
現(xiàn)在主要矛盾是春節(jié)突然增加的人流量與現(xiàn)有的動力之間的矛盾。
池子里的票遠小于出行選擇火車的需求。
因此，網(wǎng)絡訂票系統(tǒng)這樣的實現(xiàn)，對多數(shù)人是公平的。
反過來說：如果這個系統(tǒng)如TAOBAO一樣，響應充分。
會有什么結果：
就是一些人將身份證號給訂票的“機構”，專門的這些“機構”會發(fā)揮集中處理的功能。
而像一些ITER或者白領。沒有那個時間和人力來與這些“機構”竟爭。
最后這幫人還要去排除和黃牛。
-----------------------------------------------
回到現(xiàn)狀，現(xiàn)在網(wǎng)上放票的量是一定的，最終全部是訂完了，那不斷點擊，或者有運氣成分的情況下。
人們的機會的較為平等的。
作者: gotolinux 時間: 2012-01-18 16:41
云風也在他的blog中談到了隊列問題，大家可以參考下。
我們來說說排隊系統(tǒng)是怎么做的：
其實就類似我們?nèi)衢T館子吃飯拿號。只不過要防止別人偽造號插隊而已。
如果你來一個人（一次 HTTP 請求），我就隨機產(chǎn)生一個我做過一些簽名處理的號碼返回給你。暫時稱為 ticket id 。這個 ticked id 是很難偽造的。
系統(tǒng)在內(nèi)存里開一個大數(shù)組（32G 內(nèi)存夠排上億人了吧），就是一循環(huán)隊列。把這個 ticket id 放在隊列尾。
用戶現(xiàn)在拿著 ticket id 向網(wǎng)關發(fā)起請求。網(wǎng)關利用一次 hash 查詢，在內(nèi)存中的數(shù)組隊列里查到它的位置，立刻返回給用戶。用戶的前端就可以看到，他在這個網(wǎng)關（售票大廳）前面還有多少人等著。
這里的關鍵是，整個隊列都在本機的內(nèi)存中，查詢返回隊列中的位置，可以實現(xiàn)的比一個處理靜態(tài)文件的 web server 還要高效。靜態(tài)文件至少還要去調(diào)用文件 IO 呢。靜態(tài)文件 web server 可以處理多少并發(fā)量，不用我介紹了。
同時，前端會控制用戶拿著 ticket id 查詢隊列位置的頻率。高負載時可以 1s 一次，甚至更長時間。為了防止用戶自己寫腳本刷這個請求（雖然沒有太大意義，因為刷的多也不會排到前面去），如果見到同一個 ticket id 過于頻繁的查詢。比如 10s 內(nèi)查詢了 20 次以上。就直接把這個 ticket id 作廢。持有這個 ticket 的人就需要重新排隊了。
對于最后排到的人，系統(tǒng)會生成一個唯一的不可偽造的 session id ，用戶下面就可以通過這個 session id 去做實際的購票流程了�？梢赃B去真正的購票服務器，也可以通過網(wǎng)關中轉(zhuǎn)。非法的 session id 會立刻斷掉，用戶一旦知道偽造 session id 幾乎不可能，只有通過 ticket id 排隊拿到，除非是惡意攻擊系統(tǒng)，不然不會有人亂拿 session id 去試。
我們再給每個 session id 設置一個最長有效時間，比如半小時。如果超過半小時還沒有完整購票流程，那么就重新去排隊。
至于同時開放多少個 session id ，也就是相當于開放多少個購票窗口，就取決于購票系統(tǒng)能承受的負載了。不過簡單計算一下，就知道有排隊系統(tǒng)保證了良好的次序，再以計算機的吞吐能力，解決不過幾億人的購票請求，即使這些人都同來排隊，也就是一組機器幾小時的處理量而已。
作者: 無牙 時間: 2012-01-18 16:49
這還真不是設備就能解決的問題。 這個系統(tǒng)不可能盲目的擴展，這個系統(tǒng)其實上線已經(jīng)有一段時間了，不就是春運的時候大家才抱怨這個網(wǎng)站不行。
現(xiàn)在最大的問題是12306這個網(wǎng)站的構架是什么樣的？是通過什么搭建的？
LZ能不能找個了解這個網(wǎng)站結構的人介紹一下？我在網(wǎng)上搜了一下，還真沒有這方面的資料。
否則大家的討論沒有一點意義。
作者: 無牙 時間: 2012-01-18 16:50
kingstar 發(fā)表于 2012-01-18 16:40
看來各位忽視了一個嚴重的問題：
本人對現(xiàn)狀非常滿意：
------------------------------
我也有同感
作者: gotolinux 時間: 2012-01-18 16:57
無牙 發(fā)表于 2012-01-18 16:49
這還真不是設備就能解決的問題。 這個系統(tǒng)不可能盲目的擴展，這個系統(tǒng)其實上線已經(jīng)有一段時間了，不就是春運 ...
對，我們目前的狀況是，只知道系統(tǒng)有問題，具體是哪方面的問題不得而知。也就沒辦法做到具體問題具體分析了。
作者: jerrymy 時間: 2012-01-18 17:21
泱泱大國，充斥著酒囊飯袋。
作者: QQ_921 時間: 2012-01-18 20:01
本帖最后由 QQ_921 于 2012-01-18 20:34 編輯
我認為系統(tǒng)性能需要從底層進行設計:
各個省級別系統(tǒng)設計：
網(wǎng)絡：利用CDN、動態(tài)DNS等技術實現(xiàn)網(wǎng)絡高可用和負載均衡。
高性能防火墻（DDOS）、路由器、交換機，最好使用類似F5的負載均衡設備，從網(wǎng)絡層將請求分流。
每個服務器4塊網(wǎng)卡綁定加大網(wǎng)絡帶寬。
服務器
WEB服務器： 使用PC SERVER 利用F5進行分流之后，可以使用比較成熟的Nginx、MemCatch、中間件等軟件實現(xiàn)區(qū)域性的負載均衡和高可用。
數(shù)據(jù)庫服務器：可以使用小型機。利用各種同步、復制等技術實現(xiàn)讀寫分離等 高性能數(shù)據(jù)庫系統(tǒng)。
存儲：保證系統(tǒng)讀寫性能的同時，利用SAN網(wǎng)絡，將數(shù)據(jù)分級，各個級利用存儲的同步、異步技術實現(xiàn)高性能本地、異地存儲。
總部數(shù)據(jù)中心：
全國各個省級別數(shù)據(jù)庫同步到總部數(shù)據(jù)中心。做好數(shù)據(jù)的異地災備。
軟件參數(shù)優(yōu)化：
操作系統(tǒng)、WEB軟件、中間件、數(shù)據(jù)庫軟件等；存儲設備參數(shù)等。
在上線之前最好進行大量的壓力測試，盡量讓結果貼近真實�；蛘邔懸惶兹鞒蓽y試程序，利用高性能服務器進行壓力測試。
-----------------------------------------------------------------------------------------------------------
高能的系統(tǒng)絕對不是單憑大量的硬件可以堆出來的，所有功能也不是那些開源軟件都可以實現(xiàn)的。
最好是將開源軟件的優(yōu)勢與成熟的硬件產(chǎn)品結合起來，可以達到更好的效果。
-----------------------------------------------------------------------------------------------------------
程序我不懂，不敢嚇白話了。
最近在找工作，有機會搞搞鐵路的售票系統(tǒng)就好了。 ：》
作者: yanyangtian4502 時間: 2012-01-18 22:29
這個有點難，內(nèi)部材料無法搞到，可能是所謂的“國家機密”回復 96# 無牙
作者: pswen 時間: 2012-01-19 00:28
回復 24# Gray1982
你怎么知道沒放CDN呢？
作者: gotolinux 時間: 2012-01-19 01:03
pswen 發(fā)表于 2012-01-19 00:28
回復 24# Gray1982
你怎么知道沒放CDN呢？
CDN是一定有的，新聞也有報道。
| 歡迎光臨 Chinaunix (http://72891.cn/) |
Powered by Discuz! X3.2 |
