1. 淘寶技術被人稱贊

在剛剛過去的淘寶雙11大促活動中，淘寶的技術支撐受到了網民的追捧。據來自支付寶DBA@dbatools的透露：淘寶雙十一總交易金額191億，訂單1億零580萬筆，其中無線支付近900萬筆，支付寶核心數據庫集群處理了41億個事務，執行285億次SQL，生成15TB日志，訪問1931億次內存數據塊，13億個物理讀，核心MySQL集群一天支持了20億個事務。

淘寶的技術人員以實際行動讓網民折服，雖然在淘寶雙十一活動剛開始的10分鐘內的訪問高峰期內，購物車和支付寶都出現了打不開的情況，但訂單可以生成，而且白天的系統運行比較正常。雙十一期間，淘寶除了技術上的保障，還有大量的運維策略的支持，比如在峰值期間下訂單優先級最高，支付可以晚點兒，大額度的訂單優先處理等等。

淘寶網采用什么技術架構來實現網站高負載的呢?據淘寶技術人員分享，淘寶的整體架構使用了如下措施來應對：一應用無狀態(淘寶session框架);二有效使用緩存(Tair);三應用拆分(HSF);四數據庫拆分(TDDL);五異步通信(Notify);六非結構化數據存儲(TFS,NOSQL);七監控、預警系統;八配置統一管理。(摘自：http://server.51cto.com/sCollege-365024.htm)

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網站

淘寶的網站優化技術中采用了大量的緩存技術和分布式策略，火車票的狀態是實時計算，實時更新的，緩存只能解決網站前端的一小部分問題，但解決不了人們搶票和出票慢的根本問題。