2012年的春運潮造就了中國鐵路客戶服務中心12306網絡購票系統一夜躥紅，從傳統購票方式到電子商務，2012年1月1日開通的12306網絡購票系統成為了鐵道部改革的重要一步。

　　但是隨著12306系統的上線，各種關于12306系統的抱怨聲也層出不窮，不少人抱怨網上訂票系統十分“龜速” 網絡運行奇慢，網頁不時“崩潰”，平均刷新500次才能購到一張票，而且訂票過程十分繁瑣，從用戶注冊到支付成功，要13道“工序”，讓人暈頭轉向等等。

　　本來為了讓每個歸家的人更方便地買到火車票，而12306網上訂票系統這個號稱斥數千萬元巨資建立的電商的表現卻難以讓人信服，并引發了一些討論和思考，應該如何建設類似12306網上訂票系統這種大型高并發高性能網站呢?IT168記者采訪了騰訊架構平臺部劉天斯，對于大型高并發高性能網站的建設和優化，他給出了自己的建議。

　　12306訂票網站存在哪些需求特點和挑戰？

　　12306訂票網站具有分時段、分區域、高并發等特點，如何確保在高峰時段正常提供服務是一個非常大的挑戰，放眼春運期間網上訂票系統，表現為頁面訪問延時大、登錄異常、支付失敗等問題。這其中存在一定客觀因素，也不排除對流量預估不準確、架構設計不合理等情況。官方公布日均PV達10億，在高峰時段有千萬PV的訪問量，應對如此高的流量需要從帶寬、服務器、網絡、應用及業務邏輯等進行優化。

　　國內的大型網站還包括淘寶、京東、新浪等，12306的訪問模式和淘寶、京東存在哪些異同？

　　相同點都可以理解成電子商務網站，無論是業務邏輯還是應用特點都非常相似，唯一的差別是12306的流量因時段、區域更為集中，有人說像淘寶、京東搞促銷，比如”秒殺”。但”秒殺”的對象往往比較固定，后端可以通過緩存機制或靜態化來緩解數據庫I/O壓力，而12306需要每隔10分鐘更新票務信息，同時還要保持與集團其它業務系統對接，這點處理起來更為棘手。

　　淘寶、TMall、京東也曾經遭遇宕機事件，這些宕機事件和12306網站崩潰有何異同？

　　此類宕機事件原因都是相似的，無非是寬帶吃緊或服務器性能出現瓶頸(應用故障、高I/O或業務邏輯異常等)。差異點只有體現在業務層面上，促銷活動可以推遲或重新組織，但12306訂票系統不行。反之，12306有其它輔助的補救、緩解方案，如電話預定、代售點等，傳統的電子商務平臺則沒有。

　　12306訂票網站在哪些方面可能存在問題？在以上談到的問題上是否都有一些相應的優化建議呢？

　　個人認為更有價值是體現在數據分析上，如得到寬帶數據、用戶流量、區域分布、請求特點、應用瓶頸點、服務器的性能指標等等，這些數據對優化、改良現有架構非常有幫助。拋開寬帶因素，以下是對12306平臺系統架構的幾點建議：

　　一、前端優化

　　具體參考：yahoo前端優化34條規則，針對12306平臺，個人建議在沒有多運營商鏈路接入(如BGP)的情況下繼續使用CDN進行加速。動、靜態應用分離，靜態業務使用非12306.cn域名可以減少無用cookie帶來的流量。任何一個小細節在高并發下都會被無限放大(截止目前發現平臺還是以dynamic.12306.cn域名做靜態引用)。查詢頁面的結果是通過Ajax異步返回填充iframe框架來實現，這對動態CDN加速是一個挑戰，因為CDN節點并沒有真正緩存頁面中主要加速的內容。另外提高驗證碼的復雜度及多樣性，可以緩解刷票機給平臺帶來的壓力。

　　二、運用緩存

　　緩存大的好處是減少后端數據存儲的I/O壓力，從一個普通用戶訂票軌跡來看，查詢讀往往是入庫寫的好幾倍，如何減少數據庫的讀I/O對提高平臺的整體性能至關重要，比較流行的緩存技術有針對頁面及數據級，頁面級緩存有varnish、squid等，如使用CDN，頁面級的緩存可以不用考慮，重點將精力放在數據級的緩存規劃上，技術方面可以用Nosql來實現，比較成熟的Nosql有memcached、redis、mongodb等。可以根據班次、出發與目的地ID組合或出發日期進行hash分區，這樣可以很好地提高緩存命中率，減少后端數據庫的壓力。

　　三、代理層

　　引入代理層的目的是拆分業務，目前平臺絕大部分功能都共用一組WEB服務器(從域名及URI結構猜測，不一定準確)來對外提供服務，比如登錄、注冊、車票查詢、余票查詢、列車時刻表查詢、正晚點查詢、訂單管理等等，只要其中一個功能模塊出現堵塞，影響必定是全局性的。一個好的方法是優化、規范各業務URI，在代理層實現業務的劃分，可用的技術有Haproxy、Nginx等，如將/otsweb/regitNote/映射到注冊組WEB服務器，/otsweb/AppQuery/映射到查詢組WEB服務器，/otsweb/Pay/映射到支付組WEB服務器等等，如此一來，當查詢業務出現延時堵塞時不會影響到用戶支付。

　　四、數據庫層

　　之前接觸過一些政府行業的業務，數據庫服務器往往都使用一臺高端的硬件，比如小型機，在互聯網行業，尤其是類似于12306訂票系統，這往往是致命的，理由很簡單，在大流量并發下處理能力再強的服務器也吐不出數據，因為受網絡I/O、磁盤I/O、業務邏輯等方面的限制，所以必須將數據打散，方案有進行讀寫分離、分區、分片。主從模式可以很好實現讀寫分離，大部分數據庫都支持這點，除此之外還建議使用分區模式，分區策略可以根據業務特點進行，按地域進行分區是一個好主意，因為每個區域都是一個大分區，還可以從業務層面對它做二級甚至三級的"擴展分區"。需要在細化拆分與運營成本上做好平衡。另外I/O密集的點盡量使用SSD代替。

　　五、負載均衡層

　　保障一個業務平臺的高可用性，采用負載均衡策略必不可少，即使是提供給CDN的源服務器。目前有商用的F5、NetScaler、Radware等，也有開源的LVS，看成本的投入來選擇，此處不詳細展開討論。

　　六、業務層

　　此次12306網站癱瘓事件，業務層面有無優化的空間?12306網站平臺是鐵道集團在互聯網上對外服務的窗口，與電話訂票、代售點都是平級的，后端肯定還關聯著很多復雜的業務系統，在沒有對整個集團業務系統做擴容的前提下(短期內估計不能實現)，可以將網站業務平臺剝離出來，當然，完全剝離也不太實際，至少可以延長同步、一致性校驗的時間。時間的長短隨班次的發車時間成正比，因為大部分的用戶都是提前一周以上就著手預定車票。