個人積分：4952分
文章編號：53960672
12306火車票購票系統，逢假日必癱瘓，引發了強烈反響。在國慶前後，搜狐IT「問診12306」做了系列報導。當時，鐵道系統的答覆是，購票人數太多，數據量過大。但是，在前不久淘寶雙11大促活動中，淘寶雙十一總交易金額191億，訂單1億零580萬筆，其中無線支付近900萬筆，支付寶核心數據庫集群處理了41億個事務，執行285億次SQL，生成15TB日誌，訪問1931億次內存數據塊，13億個物理讀，核心MySQL集群一天支持了20億個事務。12306火車票系統和其相比，真是天上地下。12306為何如此爛？
1. 淘寶技術被人稱讚
在剛剛過去的淘寶雙11大促活動中，淘寶的技術支撐受到了網民的追捧。據來自支付寶DBA@dbatools的透露：淘寶雙十一總交易金額191億，訂單1億零580萬筆，其中無線支付近900萬筆，支付寶核心數據庫集群處理了41億個事務，執行285億次SQL，生成15TB日誌，訪問1931億次內存數據塊，13億個物理讀，核心MySQL集群一天支持了20億個事務。
淘寶的技術人員以實際行動讓網民折服，雖然在淘寶雙十一活動剛開始的10分鐘內的訪問高峰期內，購物車和支付寶都出現了打不開的情況，但訂單可以生成，而且白天的系統運行比較正常。雙十一期間，淘寶除了技術上的保障，還有大量的運維策略的支持，比如在峰值期間下訂單優先級最高，支付可以晚點兒，大額度的訂單優先處理等等。
淘寶網採用什麼技術架構來實現網站高負載的呢?據淘寶技術人員分享，淘寶的整體架構使用了如下措施來應對：一應用無狀態(淘寶session框架);二有效使用緩存(Tair);三應用拆分(HSF);四數據庫拆分(TDDL);五異步通信(Notify);六非結構化數據存儲(TFS,NOSQL);七監控、預警系統;八配置統一管理。
2. 12306網站被人詬病
淘寶強大的技術實力，很容易讓人們聯想到讓人「一票難求」的訂票網站-12306。12306網站購票難的問題幾乎成了所有人的共識。來自前支付寶架構師馮大輝(@Fenng)的這條微博翻出12306這筆賬，別有一番滋味。
以馮大輝的計算方法，支付寶11月11日一天就處理了1億零580萬條交易請求量，而12306一天處理的交易(出票量)僅僅166萬條，這還主要是集中在8點鐘開始放票之後的5分鐘時間裡。從結果來看，12306弱爆了，處理的交易量比支付寶「低了兩個數量級」還那麼弱不禁風。
馮大輝的微博馬上得到了@caoz的轉發響應，後者在9月底對12306的罵戰中一戰成名，由於觀點相似，caoz和Fenng可以稱為統一戰線——當然，眾多對12306充滿怨恨的普通購票者也與他們在感情上統一戰線。
簡單分析一下12306的購票系統，為避免「黃牛」買票，購票系統有一個業務邏輯：一個有效身份證件同一乘車日期同一車次限購一張車票。因此購買一張車票可以簡化為包含四個操作：
1) 判斷同一乘車日期同一車次是否有未預訂的空餘座位
2) 判斷這個有效身份證是否已購買過同一乘車日期同一車次的車票
3) 車票上標註的座位標記為已預訂
4) 如果沒有購買過，則該身份證預訂一張車票
人們在12306網站上購買一張票的流程如下：
1)用戶通過瀏覽器訪問系統URL
2)界面集群F5將請求轉發至某一節點，通過比較用戶數據庫的內容進行身份鑑權。
3)鑑權成功後進入訂票，提交訂票訂單(查詢流程暫不討論)界面顯示請等待
4)訂票消息被發送至總線部件(接口可用webService、RMI、甚至自定義協議都可以)
5)總線收到訂票消息、去Cache集群查詢相關車次
6)Cache根據自身維護的車次余票表，返回查詢結果，如果有餘票，轉7)。如果無票了，則總線返回界面集群「沒票了」，界面提示用戶明天再試。
7)若有餘票，則總線返回界面集群「正在出票，請等待」，並將訂票請求壓入隊列。且發消息至Cache，告訴CACHE將訂票請求加入隊列。
8)Cache收到總線隊列增加1個的消息，將自身維護的對應車次余票數減1個。
9)總線另一線程負責從隊列中取消息，並發送至出票部件。
10)出票部件產生訂票結果，並修改數據庫，發送「訂票成功」消息回總線。
11)總線將訂票成功消息直接回傳至界面集群。
12)用戶看到訂票結果。
3. 跟淘寶相比，12306網站的有獨特的技術難度
1) 火車票屬於競爭性資源。淘寶的交易是相對離散的，分散在成千上萬的賣家當中，同時對同一商家同一商品的並發購買並不是特別高。因此在數據訪問上不會有太大的鎖同一數據的瓶頸，買火車票在這方面壓力會更大，最主要的原因還是僧多粥少的。火車票是幾千人，幾萬人搶一張票，火車票的搶購場景也只有在淘寶秒殺的時候可以類比，但是網民參與的秒殺也很難成功秒殺到商品。
2) 火車票資源稀缺，需要同線下數以萬計的購票點、電話訂票等進行互斥。每張火車票都是獨一無二的，網絡售票只是數以萬計的購票終端的一個終端而已，需要跟其他售票系統保持數據一致性。淘寶的商品只需要查詢庫存量就可以了。舉個粗略的例子，火車票的供需關係可能是1：10，淘寶貨品與消費者的供需關係可能是10：1，技術革新解決不了某種商品嚴重供不應求的本質問題。淘寶上的商品天然沒有全局一致性的問題，做技術上做分區優化就簡單得多了。火車票買賣的每筆業務都要互斥，以檢查有沒有票，一個人是否買了多張票等等。從這個角度可以理解為賣票問題的技術難度大得多，屬於世界級難題。
3) 火車票的信息是實時更新的。網民的每次操作都必須到後台查詢，實時生成新的火車票的狀態信息。淘寶商品庫存信息在促銷期間不準確，這是服務端為了關鍵性能做妥協;但訂火車票，庫存信息必須是實時的。鐵道部2012年春運每天安排大約2000對列車，座位大概400萬個，因為每個座位都可能有不同的購票方式(火車票代售點、電話訂票等)，所以都需要計算，提前10天預售，應該有點類似於taobao同時提供400萬件商品的秒殺活動。
4) 票務業務的複雜性非商品信息可比。選票最大的問題不是直達，是換車!只要有換車，計算量級都是「次方」往上增加。比如上海-西安，中間在鄭州換。但系統計算的時候會出現「上海-北京-西安」的路線，這條線路是沒有選的，但會消耗計算資源，2000條線路+臨時車+換乘，還有就是瞬間的並發，這個也是一個問題。
5) 12306網站後面的票務系統問題。12306網站不是一個孤立的系統，雖然這網站也很多地方可以優化，但估計最大的瓶頸是後面那個和全國的代售點火車站共用的票務系統。真正的火車票數據庫是在鐵路系統中獨立存在的，這個鐵路系統反應慢才是制約12306網站慢的主因。所以最大問題可能不是負載並發問題，而是老票務系統的問題。票務系統採用的是突然放票，而有的票又遠遠不夠大家分，所以，大家才會有搶票這種有中國特色的業務的做法。於是當票放出來的時候，就會有幾百萬人甚至上千萬人殺上去，查詢，下單。幾十分鐘內，一個網站能接受幾千萬的訪問量，這個是很恐怖的事情。據說12306的高峰訪問是10億PV，集中在早8點到10點，每秒PV在高峰時上千萬。這需要逐步全面革新。
6) 獨特的車票預留問題。傳統票務系統有一個比較複雜的地方就是各種預留票規則，每個城市，每個節日都有很多的複雜留票規則，導致很多時候頭十天一張臥鋪都沒有，但是等到最後就有很多票，這些使本已稀缺的資源更加緊張。
4. 結論：淘寶的網站優化技術大多不適用於12306網站
淘寶的網站優化技術中採用了大量的緩存技術和分佈式策略，火車票的狀態是實時計算，實時更新的，緩存只能解決網站前端的一小部分問題，但解決不了人們搶票和出票慢的根本問題。
個人積分：5992分
文章編號：53961514
個人積分：4588分
文章編號：53962270
fedora wrote:
大陸的市場規模太大了...(恕刪)
真正的問題在於心態, 搞 opensource 也就是開源基本要先 open mind, 然後企業有其核心業務或掌握關鍵組件, 再利用開源去打開出海口. 可以看看 kernel.taobao.org, 淘寶 kernel team 的工作項目都在上面, 已完成的未完成的. 所有的 patch 都 contribute 到 upstream kernel git, 幫公司在上游建立了很好的credit和形象, 不只心態, 連資訊都完全開源.
opensource的力量是很強大的, 尤其對於後進追趕者特別有用, 台灣公司應該多想想opensource, open hardware 的商業運作. open在台灣直到現在都還是停在社群, 新潮, fun的階段.
台灣軟硬體產業心態封閉, 無論大小企業都一樣. 一昧要求別人開放, 最好是別人都開放只有我封閉. 只要我能接別人的 resource 就可以, 別人要接我的門都沒有. 我最好知道別人的code, 別人要 review 我的門都沒有. 只有我能用別人的 opensource, 自己改完的 code, patch, framework 抓得緊緊的孤芳自賞直至公司倒閉.
只學到開源的型, 沒有真正 open mind 去想公司的商業應用模式, 辦再多活動 for fun 都無濟於事.
個人積分：5312分
文章編號：53964198
個人積分：1284分
文章編號：53970942
而且就算進到首頁，也不表示接下來就一路順暢。因為只要點選任何一個連結，表示又要跟網路上其他用戶去競爭那400MB的窄門~~~ 每點選一次連結，就是重新競爭一次。這樣的設計當然讓所有網路用戶反覆去搶奪那400MB的頻寬，起碼要競爭成功四次才能進入付款畫面，這機率有多小? 為什麼不讓第一次已經成功進入網站的使用者能保證持續完成購票任務呢?
以下是我想的解決方法~~~~當中某些技術是我已經用在我製作的ERP系統當中~~~
要減少這種無謂的頻寬浪費，整個寬宏購票網站設計就要放棄傳統的設計方式，直接採用靜態HTML+JavaScript運算的方式設計，用IFRAME方式分散使用者點選不同場次與不同座位區塊，直接去對應不同座位區塊的單獨訂購伺服器。這樣就不會有重複載入浪費頻寬的問題(因為主頁面不需要重複載入)，也可以保證進入的使用者就可以完成選位，更不用集中塞在同一條線路上。
另外也要放棄傳統的單一資料庫設計觀念。這種集中式資料庫才是製造流量瓶頸的關鍵。配合網頁上分割的訂位頁面，就搭配一台單獨的伺服器來處理訂位(假設分20區就有20台獨立的對應處理網頁伺服器)。每個資料伺服器的網頁首頁不是HTML，而是一個純文字的.js檔案，裡面就是一個陣列而已。這個.js檔案直接被使用的瀏覽器讀取，利用Javascript來繪製出座位圖。由於javascript是使用者端瀏覽器去執行，不像ASP必須由伺服器來執行，所以可以避免伺服器被大量使用者的呼叫需求給撐死。這個js檔案內容就是空位號碼，每個伺服器就處理500到600個就夠了。隨著座位越來越少，檔案也會越來越小，當訂位全部完成時，JS檔案也清空剩下END，這樣前端HTML也就知道座位都訂完，整個區塊可以畫出一個X。就算一開始都是空位，宣告一個這樣都是空位的檔案，也不過只有2K而已。使用者以滑鼠點選哪個區塊，該區的伺服器才需要回傳座位資料檔，這樣就不會回傳一些不必要的資料浪費頻寬。
ps. JS檔案只是專門餵給訂票者瀏覽器的純資料檔，不是存放真正訂購者訂購資料的檔案。
以400MB的頻寬來說，伺服器以AJAX技術每秒回傳一個2K大小的檔案，理論上可以滿足204800個網路需求。而20台區域定位伺服器能否滿足二十萬個連線?平均一台要處理一萬個，每台的頻寬占用20M。以寬宏的IIS 6來說，建議最好不要超過8700個 (http://blogs.msdn.com/b/david.wang/archive/2006/04/12/howto-maximize-the-number-of-concurrent-connections-to-iis6.aspx )，因為每個連線都會占用一定的記憶體空間。超過限制IIS就掛了。那我保守一點，設定5000個連線，占用10M頻寬。這樣訂位資料傳送每秒鐘可以滿足起碼十萬個網路使用者。
所以要跑大量連線的IIS，記憶體可不能太吝嗇。我不曉得寬宏是在哪種等級配備的伺服器上安裝windows 2003 server，IIS又設定多少連線上限。但是目前看來基本架構設計就有問題，網頁內容根本沒有最佳化，無用的資料佔據了寶貴的對外頻寬，過時的連結換頁設計讓使用者一再重複競爭頻寬。結果就是惡性循環，大家都連不上~~~
至於訂位競爭問題，其實也好解決~~~
個人積分：12923分
文章編號：53972248
vt_hunter wrote:
要完整載入寬宏首頁，...(恕刪)
這樣看起來，它應該使用 CDN 服務（逆向 Proxy 快取代理）。
把 程式主機、多媒體主機（圖片、影片）、資料庫主機，都分開
程式主機，不放任何多媒體資料，就只有程式碼 html、css、php、javascript 等等。
多媒體主機（圖片、影片、網頁美化），資料不直接和公司伺服器提取，一律透過租用的 CDN 服務。
多媒體資料屬於靜態資料，設計好就不會改變，也不牽涉到資料庫或金流服務，所以讓很多台第三方的 CND 服務伺服器去分擔負載、分流，是 OK 的。
***********************************************
而如果對第三方 CDN 服務覺的不信任
或也可以租多一點的虛擬主機（不同家、不同線路的），去分擔多媒體的資料。
跳伺服器（分流），索取資料，有幾種方法：
● 使用最簡單的 DNS 跳號，分散負載。
named 正解檔
------------------
images.xxx.com in A 11.22.33.44
images.xxx.com in A 22.33.44.55
images.xxx.com in A 33.44.55.66
-------------------
每次和 dns 查詢主機 IP，就會輪流回報不同的 IP（各台租用的虛擬主機）。如此可達到跳台的效果。
不過這有個缺點就是：大部份的 ISP DNS 伺服器，查詢得到正解結果後，都會快取 幾分鐘～24H 不等。
超商有可能全國都採用同一家的網路，查詢的 DNS Server 都一樣。會造成查到的都是快取資料，就無法達到跳台的目的。
● 網頁程式碼，「變數」跳台
舉例 PHP，輸出 html 的貼圖標籤：
echo "〈 img src = "http:\/\/${主機IP}\/圖片.jpg" 〉" ;
絕對路徑，"主機位址" 那部份使用一個「變數」，比如：${主機IP}
這個「變數」會從：所有可用的分流主機 IP 列表資料中，自動亂數取一個來產生。
當然程式碼沒有這麼簡單，要亂數取列表，需要另一段程式碼，這只是 html 輸出貼圖標籤的部份。
如此一來，當每位使用者開這個網頁時，讀取圖片都會從不同台主機去讀取。就可以達到分流效果。
這個方法比較可靠。不像 DNS 跳號，會受 DNS 快取影響。
不過這方法只適用在 html 中可以連結的檔案，比如：圖片、影片...之類的。
這「變數跳台」的方法，還可以進一步最佳化：
先取得 client端 瀏覽者的 IP ，分析他用的是哪一家的 ISP 網路
然後網頁中連結多媒體檔案時，主機位址，直接給針對那家 ISP 網路最優化的主機位址。
譬如說，來自 HiNet 的瀏覽者，多媒體檔案連結，就導到架設在 HiNet 底下的主機。
理論上，同一 ISP 網路下的主機，有最優的響應速度。（網內通常都比較快，因為經過的路由節點少）。
此外各分流主機，並不須真的是放圖片的，因為太多台，一個小更動什麼的，同步資料會很麻煩。
分流主機，可以乾脆就是一台 逆向 Proxy 網頁快取代理（即自架 CDN 服務主機）。
如此一來，就不必去同步資料，因外它只是快取代理的，純粹分流用的，會自動抓最新資料來快取。
****************************************
分流除了分散伺服器 CPU 負載、流量負載
還有一個好處：可節省龐大經費
舉例租用一條 400M 專線，也許一個月要十幾萬
但市面有那種 100M/100M 對稱固定 IP 的網路，一個月才 2千元左右，租個 4條 = 約1萬元
每台主機配一條，雖只有 100M，但利用「跳台分流」的方式，總流量其實也有 400M。
網路成本僅須 1/10 不到，甚至 1/20 不到。
不過這種多線負載平衡的方法，並不是無限擴充的，ISP 有所謂集縮比，光纖到路邊光化箱如果只有 1G，那就算租 20條 100M 的，出去也是只有 1G 或更小。
所以要多線負載平衡的，要租不同媒介線路的，FTTH 光纖、VDSL 電話線、CATV同軸、最好不同家 ISP 的，不同媒介的，才不會源頭都是同一個，擠在源頭。
假若租不同家 ISP 的線路，各自分流一台主機，再搭配程式碼分析瀏覽者 IP，對應到最佳的分流主機（同一 ISP 網內的主機），效果更好。
個人積分：4588分
文章編號：53976152
個人積分：43分
文章編號：53993658
個人積分：2204分
文章編號：59247249
