原文地址：http://blog.csdn.net/xsc2001/article/details/8521069

一、引言

隨著春節的臨近，大家都忙著從網上刷票，隨之而來的就是對12306訂票網站的質疑聲。今天就針對這個問題和朋友還討論了一番，有感於此，本人從技術的角度對此進行分析並對整個系統的架構進行了一下重構構想。

首先整個售票系統是一個非常龐大而復雜的系統，是一個高負荷、高並發的雲平臺，其規模甚至比淘寶大2至3倍，而且對於數據的實時性要求非常高。光是12306網站系統的日訪問量達到了15億次，如果加上各個代售點和車站售票系統，則高峰時段數據訪問層的並發量在千萬級別。如此大的訪問和並發量，如果沒有好的架構設計肯定保證了不系統的穩定性和健壯性。

其次，本人覺得12306網絡訂票系統是在鐵道部原有的聯網售票系統基礎上開發的，所以其原有的數據架構很關鍵，它直接影響到整個系統的擴展性和穩定性。設想一下如果整個系統全部進行重構那是多麽龐大的工程，這不僅涉及到整個架構的重新設計、服務系統開發，還有一個更繁重的工作就是所有火車站的售票系統和代售點系統都將全部升級，至於12306網絡訂票系統肯定不會出太大的問題，但是對於車站售票系統可是一個很大的考驗，不能有半點的閃失。因而我想鐵道部也不會冒這個風險。正是因為12306是在原有的架構上增加和擴展的，所以才有了目前的種種問題。如果一切從頭架構反而好多問題迎刃而解。

二、總體架構

這裏我就對這個新的系統架構做一個詳細的設計，首先要認清此應用是一個雲平臺的典型應用，系統要按雲平臺的思想分層設計，從上而下分為三層，即：應用層、數據訪問層、數據層。每一層之間是松散耦合。合得每一層具有很強的擴展性和伸縮性。每一層內部都是基於集群技術，分組部署，每一組處理單元都是即插即用，可根據計算壓力動態擴充，其大致的結構如下圖：

應用層：主要是指各種售票和訂票系統，主要有三種，如車站售票系統、代售點系統及12306網絡訂票系統。其中前兩個是C/S結構的應用，後一個是B/S應用模式。其客戶端應用服務器之間增加一個負載均衡服務，這有利於系統的並發，可以有效地根據當前用戶量和訪問情況自動地分配相對壓力較小的服務器。

數據訪問層：主要是將業務應用與底層數據庫之間的操作接口專門獨立出來，業務應用訪問數據不是直接訪問數據庫，而是通過數據訪問層進行間接地訪問和操作。這樣的好處是可以解決數據訪問的並發瓶頸，可以根據系統的壓力情況動態地調整和部署訪問層。

數據層：根據車次和地域將車次的余票信息分別存儲在很多個數據中心上，每一個數據中心是一組服務器。這樣將眾多的並發用戶根據查詢車次分散到多個數據中心上去。從而降低單點壓力，提高整體的並發性能。如果數據訪問是一個大瓶頸則可增加數據中心的節點而減小數據中心的粒度（也就是每個數據中心減少車次數量），可提高數據訪問的速度。

三、詳細架構

系統整體按分層架構處理，每一層都是可註冊、可插拔的體系，這種架構的好處是每一層都可以分層優化，而互不影響。並能根據實際運行的情況對並發和訪問量過大的實體層進行動態擴容，很容易提高系統的並發和穩定性。

此架構很好地解決了應用服務器和數據訪問的瓶頸問題，如果應用服務器壓力大則可以通過註冊表對應用服務器擴容，並通過負載均衡均衡地訪問各個應用服務器。如果數據訪問是一個瓶頸則可增加數據加心的方式來解決數據訪問擁擠情況。

對於數據層系統按車次對所有的車次車票信息進行分組，每一組是一個數據中心，數據中心的大小可隨時調整。這樣可以把用戶對數據的訪問分散到多個節點上去，從而降低數據中心的壓力。每一個數據中心由若幹臺機器組成，一臺主數據服務器，若幹從數據服務器。主數據是用於給用戶出票，每一個接口調用都需要加鎖，保證票數數據修改的原子性，其所管理的車次和車票數據在內存中高速緩存。同時每隔一定的時間周期同步到從數據服務器上，從數據是用來提供查詢的數據副本，它把大量的查詢操作分散到從數據服務器上。其數據訪問的流程如下：

大話鐵道部12306訂票系統雲架構