12306與中國著名的互聯網企業進行合作解決—整體架構

針對類似于12306的高性能高并發系統設計，童文童認為12306網站完全可以和新浪、淘寶等大型互聯網公司進行合作，通過他們的平臺進行登錄，利用這些大型互聯網公司的資源與12306的平臺相對接，以分散海量并發所帶來的壓力，具體架構設計可參考上圖。

在集成架構方面，可采用以消息隊列為核心的異步機制把新浪微博、淘寶、騰訊這些公司平臺提供的互聯網售票應用與12306互聯網售票數據服務系統集成起來。這種消息隊列為核心的異步機制進行解耦的架構有幾個最大的好處：

當大量的并發的用戶(例如千萬級別的)在幾分鐘之內甚至1分鐘之內壓到新浪微博、淘寶、騰訊這些公司平臺提供的互聯網售票WEB應用，所產生的壓力 由相應的網絡、均衡負載器、互聯網售票WEB應用的服務器給分別的承受掉。并且轉換成相應的消息異步的傳到12306互聯網售票數據服務系統進行處理，這 樣轉換給12306互聯網售票數據服務系統的并發壓力將會下降幾個數量級。

12306互聯網售票數據服務系統可以根據相應的需求按需配置所需要的資源(例如機器數目和線程數目進行處理)對不同的隊列進行處理。并且由于采用 了消息隊列為核心的異步機制，在高峰期的時候肯定是大量的消息涌入以期待處理，在沒有采用消息隊列為核心的異步機制的時候我們需要的一次一條條進行處理， 而這種情況下例如我們可以對登錄實現一次處理10條消息的批量處理，從而大大地降低對數據庫的壓力。

12306可以將前端交給這些公司合作一起解決高并發問題，當然也可以自己獨立解決前端的并發問題，以避免合作過程中可能出現的問題。這對于整體系 統架構設計而言，并不會有太大的變化，只是需要投入大量的成本而已。

焦點四：軟件層需要做哪些工作?

軟件層將直接決定整個系統應對高并發的能力，其將應用服務器與數據庫、存儲結合成為一個有機的整體，使數據在這些IT設備之間傳輸，可以說軟件層做得好與不好可能性能差異能達幾倍到一個量級。那么在以高并發為前提的情況下，軟件層要做什么呢?

百度首席架構師林仕鼎認為在解決請求尖峰時可采用threadpool或event-driven兩種做法。這兩種做法都需要自己維護請求隊列，也帶來了提高穩定性的可能性。簡單地說，就是增加flow control機制，上游根據下游的負載做throttling，反饋可以有ack/poll等多種做法，有時需要由最下游一路反饋到最前端。并采用延遲截斷，對于太老的請求，直接給出拒絕響應，讓它在應用層重試。

4399架構師曹政則提供了更多更具體的方式，他認為可將存儲key- value化，因為基本上查詢都是直線式的，所以key-value就是很好的工具;因為出票可能需要找一下車次，座位，只能一一對應的查詢就不好用;弄 個redis帶個列表結構進去就可以了。春節放票總共多少張?又不是一次放出來，每張票對應一個key，一個value，能吃多少內存?后面跟個數據庫做 同步，這點數據量對于現在的服務器來說根本不是問題。并且在注冊登陸也可以在 mysql基礎上弄個redis掛在前頭響應以提高查詢速度。

實際上，在12306在線購票系統中，查詢操作是很常見，因為你需要查詢車次，還需要查詢余票?；谶@點，曹政認為可將查詢結果緩存化、靜態化，這可通過兩個步驟實現，起始地，目標地查詢 – 常見查詢目標(如北京到成都)全部預制緩存。非常見查詢目標，基于第一次查詢的結果緩存，這樣查詢車次基本上無壓力。

查詢有票狀態就更簡單了，因為票數只有有票，無票兩個狀態，某日某車次作為一個key-value類型存儲(仍用redis即可)。某類車票發生從 有到無或從無到有的變化，才通知緩存更新。更新是后臺通知的，而非基于用戶查詢。比如某車次硬臥票售完，通知一次更新，硬座售完，通知一次更新，軟座售 完，通知一次更新。以此類推，這樣的緩存更新次數極少。而且可以給前端返回甚至靜態結果(基于查詢條件生成靜態結果，是個Seoer都會的，后臺在票數變 化時通知更新，這樣結構上就與前端查詢無關了，而且一樣可以保持實時性)。

最后還可對前端緩存進行處理來提高響應速度?？赡艽蠖鄶等硕急?0億PV給嚇到了，但實際上這里面有很大的水分，因為有很多可能是利用代碼或者腳本 進行的自動刷新，自然而然就會產生較大的泡沫，而實際上絕對不會有那么多?；谶@點，則可通過緩存來避免“爆機”，并且有例子證明，這樣做的效果是能夠應 對一小時20億的刷新，12306的10億刷新根本就不成問題。

當然，網上的各種關于軟件層的建議還有很多很多，包括之前提到的云風的排隊系統也應該屬于軟件層的內容，因為篇幅的原因，在此我們僅選取了幾個較為典型的建議。

焦點五：系統該如何優化?

系統優化是必不可少的環節，每一個成熟的網站和系統都是通過不斷優化而來的。而12306網站最早暴露出來的也是優化問題，隨后經過網友深挖，從12306網站前端的網頁設計到后端的數據、緩存、負載均衡、數據分區等一系列問題都提出不同的優化方案。

12306網站前端性能優化技術分析

從時間上來看，首先引發12306網站擁堵的是網頁的問題，從12306的首頁來看，其總文件大小在900K左右，在極端情況下，如果所有人都是第 一次訪問的話，那么每個人都需要下載1M大小的文件，如果需要在兩分鐘內返回的話，那么所需的帶寬需要66Gbps，當然這是極端的情況。那么在這種情況 下就需要對網頁大小進行調整，盡量少用圖片，因為圖片非常消耗帶寬，在這種高并發的情況下，即使1K大小的文件也極有可能引發“蝴蝶效應”。

同時，由于對12306網站的訪問是部分地域的，可能不同的Web服務器承受這不同的壓力，這種情況下可通過DNS負載均衡器將用戶訪問平均分配到各個 Web服務器上，因為Http的請求都是短時的，所以很簡單的負載均衡器就能完成這一動作。并且，CDN在這個環節能夠提供很大的幫助。

并且，IBM 軟件架構師景文童認為，12306網站在后期應該增加對智能移動終端的支持，那么從當前的整體帶寬來看，盡量不用或少用圖片，并對網頁進行優化將有助于提 高網站的訪問速度。在都不是非首次訪問的前提下，瀏覽器會緩存相當一部分內容，這就會明顯減少帶寬占用，于是負載一下子從前端遷移到了后端，數據處理瓶頸 一下就凸顯出來，訪問者不斷刷出的500錯誤即是明證。

除了上述所說的這些之外，還可通過減少前端網頁的鏈接數、頁面靜態化以及之前提到的緩存技術來對網站前端進行優化。這些方法能夠明顯解決用戶無法登 陸或者訪問緩慢等問題，但并不能解決問題真正的實質——購票。因為涉及到對數據庫進行查詢以及寫入等操作，后端優化就顯得尤為重要。

12306網站后端性能優化技術分析

關于后端性能優化技術，陳皓在其博客中表示，可通過數據冗余、數據鏡像、數據分區以及后端的動態負載均衡來達到提高訪問速度的目的。

數據冗余就是將數據庫的數據冗余處理，也就是減少表連接這樣的開銷比較大的操作，但這樣會犧牲數據的一致性。但這樣做的風險較大，并且現在常用的方法就是利用NoSQL來做數據，數據冗余了，訪問加快了，但是數據一致性就會存在較大的問題。

利用后端優化來提高訪問速度的第二個方法則是數據鏡像，現在幾乎所有的主流數據庫都支持鏡像。鏡像的好處就是可以做負載均衡。把一臺數據庫的負載均 分到多臺上，同時又保證了數據一致性(Oracle的SCN)。最重要的是，這樣還可以有高可用性，一臺廢了，還有另一臺在服務。但數據鏡像后的數據一致 性仍然是一個復雜的問題，因為要對單條數據進行分區，將其均分到不同的服務器上。

數據鏡像不能解決的一個問題就是數據表里的記錄太多，導致數據庫操作太慢。所以，把數據分區。數據分區有很多種做法，一般來說，數據分區包含以下幾 種主要的方式：把數據把某種邏輯來分類、把數據按字段分，也就是豎著分表、平均分表或者同一數據分表等。

數據分區可以在一定程度上減輕負載，但是無法減輕熱銷商品的負載，對于火車票來說，可以認為是大城市的某些主干線上的車票。這就需要使用數據鏡像來 減輕負載。使用數據鏡像，你必然要使用負載均衡，在后端，我們可能很難使用像路由器上的負載均衡器，因為那是均衡流量的，因為流量并不代表服務器的繁忙程 度。因此，我們需要一個任務分配系統，其還能監控各個服務器的負載情況。當然服務器負載均衡的技術有很多，每種方法都有各自的優缺點，這個可能要根據實際 情況進行選擇。

12306高性能高并發系統特點總結

實際上，通過上述的這么熱議焦點，我們可以發現，要建設一個類似于12306在線購票系統還是面臨著諸多難題，從系統層面上講，其必須必備高性能、 高可擴展性以及高可靠性等特點。同時，整個系統從架構設計到網頁設計，甚至每段代碼的編寫都必須經得起嚴格的考驗，網頁代碼力求簡單、實用，因為那怕一小 段代碼問題在面對瞬時海量高并發時都有可能引發“蝴蝶效應”。

在春運期間，對于廣大的貧苦老百姓而言，火車票的超高性價比和相應的方便性，使得每張票都成為稀缺資源和緊俏商品。而在12306系統開始售票那一 瞬間，必然有成千上百萬的人一擁而上。盡管從鐵道部發布的數據來看，其最高的一天一共賣出了188萬多張票，這個數據放在一天來看的話，確實不多。但是如 果是在短短幾分鐘之內呢?那整個系統承受的壓力自然不言而喻。

盡管此次鐵道部采用的是分地區分時段售票，但所售票數跟搶購人數之間是沒有關系的。同時因為在最早那一時段售票時就沒有解決并發所帶來的壓力，使得 已經開始發售第二時段的票時，仍有大量的人在不停地刷新，使得訪問人數再次增加，系統壓力亦隨著增長。那么整個系統就必須使得在第一時段內賣出所有的票， 而這個時間點可能就只有短短的幾分鐘(開始售票那幾分鐘，因為火車票是遠遠小于想要買票的人數的)。

除了整個系統需要滿足高性能需求之外，還得同時具備高可擴展性(高可伸縮性)。因為從歷年來的經驗來看，鐵道部的并發高峰通常是在節假日發生，如五 一、十一長假等，春運則是最大的一個并發高峰。而目前的情況看來，12306在線購票系統雖然不能應對春運高峰，但在平時售票卻還是沒有問題。這就使得這 個系統必須具備高可伸縮性，在并發高峰來臨之前，能夠通過簡單的加機器或者與新浪、淘寶、騰訊等大型互聯網公司合作來共同應對這些并發高峰。

在具備上述兩個特點的同時，還得具備高可靠性。這么大的并發單靠一臺機器是不可能實現，必須采用集群來分散壓力。而在集群中，必須防備機器故障，單臺機器故障之后不能影響其他機器的正常運轉，并且還必須在短時而將故障修復。

除了上述三大必備性能之外，如果想擁有更好的用戶體驗，那么還得具備一些其他的特點。目前移動互聯網正飛速向前發展，各種智能移動終端(如智能手機、平板電腦)層出不窮，作為一個方便可行的系統，那么還應該對這些移動終端提供支持。

另外，從現今角度除外，鐵道部所售出的總票數是遠遠小于想要買票的人數的，供小于求，必然導致投機分子的存在，如“黃牛”，那么這個系統就還得作出 一些措施來防范利用腳本、程序進行刷票的行為。刷票也是增加并發的一個因素之一，防止刷票也從另一個方面減少了并發，提高整個系統的可用性。