昨天，2012年1月11日，網友 @fenng 寫了一篇文章，批評鐵道部火車票網上訂購系統，http://www.12306.cn [1]。同時在新浪發了一條言辭激烈的微博，“去你的‘海量事務高速處理系統’”，引起熱議 [2]。
春節將到，大家買不著車票，趕不上大年三十與家人團聚，急切心情可以理解。但是拍桌子開罵，只能宣泄情緒，解決不了實際問題。
開發一套訂票系統并不難，難在應對春運期間，日均 10 億級別的洪峰流量。日均 10 億級別的洪峰請求，在中國這個人口全球第一大國，不算稀罕，不僅火車票訂票系統會遇到，而且電子商務在促銷時，也會遇到，社交網站遇到新聞熱點時，也會遇到。
所以，能夠在中國成功運行的云計算系統，推廣到全球，一定也能成功。
但是在美國成功運行的云計算系統，移植到中國，卻不一定成功。
如果我們能夠設計建造一套，穩定而高效的鐵路訂票系統，不僅解決了中國老百姓的實際問題，而且在全球高科技業界，也是一大亮點，而且是貼著中國標簽的前沿科技的亮點。
于是軟件工程師們獻計獻策，討論如何改進 12306 網上購票系統
[3]。其中比較有代表性的，有兩篇 [4,5]。
網友的評論中，有觀點認為，[4] 利用“虛擬排隊”的手段，將過程拉長負載降低，是網游的設計思路。而 [5] 利用緩存技術，一層層地降低系統負荷, 是互聯網的設計思路。
個人認為，[4] 和 [5] 并不是相互排斥的兩種路線，兩者著重解決的問題不同，不妨結合起來使用，取長補短。
下面介紹一下我們的設計草案，追求實用，擯棄花哨。拋磚引玉，歡迎拍磚。
圖一。12306.cn 網站系統架構設想圖。
Courtesy
http://i879.photobucket.com/albums/ab351/kan_deng/12306.png
圖一是系統架構圖，典型的“展現層”/ “業務層”/ “數據層”的三段論。
用戶接入有兩類，一個是運行在電腦里的瀏覽器，例如 IE，另一個是手機。
無論用戶用電腦瀏覽器，還是手機訪問 http://www.12306.cn 網站，用戶請求首先被網站的負載均衡器接收。負載均衡器連接著一群門戶服務器，根據各個門戶服務器的負載輕重，負載均衡器把用戶請求，轉發到某一相對清閑的門戶服務器。
門戶服務器的任務類似于收發室老頭兒，它只讀每個用戶請求的前幾個 bytes，目的是確定用戶請求的類型，然后把請求投放到相應類型的隊列中去。門戶服務器的處理邏輯非常簡單，這樣做的好處，是讓它能夠快速處理大批量用戶請求。
根據 [5] 的分析，12306 處理的用戶請求，大致分為三類，
1. 查詢。用戶訂票前，查詢車次以及余票。用戶下訂單后，查詢是否已經訂上票。
2. 訂票，包括確定車次和票數，然后付款。用戶付款時，需要在網銀等網站上操作。
3. 第一次訪問的用戶，需要登記，包括姓名和信用卡等信息。
三類請求的業務處理過程，被分為兩個階段，
1. 運行于緩存中的任務隊列。設置隊列的目的，是防止處理過程耗時太長，導致大量用戶請求擁塞于門戶服務器，導致系統癱瘓。
2. 業務處理處理器，對于每一類業務，分別有一群業務服務器。不同業務的處理流程，各不相同。
圖二。12306.cn 網站查詢和訂票業務流程設想圖。
Courtesy
http://i879.photobucket.com/albums/ab351/kan_deng/12306-1.png
圖二描述了查詢和訂票，兩個業務的處理流程。登記業務流程從略。
查詢的業務流程，參見圖二上半部，分五步。
這里有兩個問題需要注意，
1. 用戶發出請求后，經過短暫的等待時間，能夠迅速看到結果。平均等待時間不能超過 1 秒。
2. 影響整個查詢速度的關鍵，是“查詢服務器”的設計。
查詢任務可以進一步細化，大致分成三種。
1. 查詢車次和時間表，這是靜態內容，很少與數據庫交互，數據量也不大，可以緩存在內存中。
車次和時間表的數據結構，不妨采用 Key-Value 的方式，開發簡單，使用效率高。Key-Value 的具體實現有很多產品，[5] 建議使用 Redis。
這些是技術細節，不妨通過對比實驗，針對火車票訂票系統的實際流量，以及峰值波動，確定哪一個產品最合適。
2. 查詢某一班次的剩余車票，這需要調用數據庫中不斷更新的數據。
[5] 建議把剩余車票只分為兩種，“有”或“無”，這樣減少調用訪問數據庫的次數，降低數據庫的壓力。但是這樣做，不一定能夠滿足用戶的需求，說不定會招致網友的批評譏諷。
[4] 建議在訂票隊列中，增加測算訂票隊列長度的功能，根據訂票隊列長度以及隊列中每個請求的購票數量，可以計算出每個車次的剩余座位。如果 12306.cn 網站只有一個后臺系統，這個辦法行之有效。
但是假如 12306.cn 網站采用分布式結構，每個鐵路分局設有子系統，分別管理各個鐵路分局轄區內的各個車次。在分布式系統下，這個辦法面臨任務轉發的麻煩。不僅開發工作量大，而且會延長查詢流程處理時間，導致用戶長久等待。
3. 已經下單的用戶，查詢是否已經成功地訂上票。
每個用戶通常只關心自己訂的票。如果把每個用戶訂購的車票的所有內容，都緩存在內存里，不僅非常耗用內存空間，內存空間使用效率低下，更嚴重的問題是，訪問數據庫過于頻繁，數據量大，增大數據庫的壓力。
解決上述分布式同步，以及數據庫壓力的兩個問題，不妨從訂票的流程設計和數據結構設計入手。
假如有個北京用戶在網上訂購了一套聯票，途經北京鐵路局和鄭州鐵路局轄區的兩個車次。
用戶從北京上網，由北京鐵路局的子系統，處理他的請求。
北京鐵路局的訂票服務器把他的請求一分為二，北京鐵路局的車次的訂票，在北京子系統完成，鄭州鐵路局的車次在鄭州子系統完成。
每個子系統處理四種 Key-Value 數據組。
1. 用戶ID：多個 (訂單ID)s。
2. 訂單ID：多個 (訂票結果ID)s。
3. 訂票結果ID: 一個 (用戶ID，車次ID)。
4. 車次ID：一個(日期)，多個 (座位，用戶ID)。
北京訂票服務器完成訂票后，把上述四個數據組，寫入北京子系統的數據庫，同時緩存進北京的查詢服務器，參見圖二下半部第6步和第7步。
鄭州訂票服務器完成訂票后，把上述四個數據組，寫入鄭州子系統的數據庫，同時緩存進北京的查詢服務器，而不是鄭州的服務器。
讓訂票服務器把訂票數據，同時寫入數據庫和查詢服務器的緩存，目的是讓數據庫永久保留訂票記錄，而讓大多數查詢，只訪問緩存，降低數據庫的壓力。
北京用戶的訂票數據，只緩存在北京的查詢服務器，不跨域緩存，從而降低緩存空間的占用，和同步的麻煩。這樣做，有個前提假設，查詢用戶與訂票用戶，基本上是同一個人，而且從同一個城市上網。
但是這里有個缺陷，某用戶在北京上網訂了票。過了幾天，他在北京上網，輸入用戶ID和密碼后，就會看到他訂購的所有車票?？墒怯诌^了幾天，他去了鄭州，從鄭州上網，同樣輸入用戶ID和密碼，卻看不到他訂購的所有車票。
解決這個缺陷的辦法并不麻煩，在用戶查詢訂票信息時，需要注明訂票地點，系統根據訂票地點，把查詢請求轉發到相應區域的子系統。
另外，每次訂票的時候，網站會給他的手機發送短信，提供訂票信息，參見圖二下半部第8步和第9步。
以上是一個初步設計，還有不少細節需要完善，例如防火墻如何布置等等。
這個設計不僅適用于單一的集中式部署，而且也適合分布式部署。
或許有讀者會問，為什么沒有用到云計算？其實上述架構設計，為將來向云計算演變，留下了伏筆。
在上述架構設計中，我們假定每個環節需要用多少服務器，需要多大容量的數據庫，預先都已經規劃好。
但是假如事先的規劃，低于實際承受的流量和數據量，那么系統就會崩潰。
所以，事先的規劃，只能以峰值為基準設立。
但是峰值將會是多少？
事先難以確定。即便能夠確定峰值，然后以峰值為基準，規劃系統的能力，那么春運過后，就會有大量資源冗余，造成資源浪費？
如何既能抗洪，又不造成資源浪費？解決方案是云計算，而且目前看來，除了云計算，沒有別的辦法。
Reference，
[1] 海量事務高速處理系統。
http://www.douban.com/note/195179318/
[2] 去你*的‘海量事務高速處理系統’。
http://weibo.com/1577826897/y0jGYcZfW
[3] 火車訂票系統的設想。
http://weibo.com/1570303725/y0l9Y2mwE
[4] 鐵路訂票系統的簡單設計。
http://blog.codingnow.com/2012/01/ticket_queue.html
[5] 鐵路訂票網站個人的設計淺見。
http://hi.baidu.com/caoz/blog/item/f4f1d7caee09b558f21fe780.html
題圖來自
Designyoutrust
一、環境
數據庫服務器：Oracle 9i2
操作系統：Windows XP SP2
JBoss版本：4.2.2
JDK：Sun 1.5.0.13
網絡配置：同一機器的一個網卡上綁定兩個ip地址192.168.1.18和192.168.1.147
二、配置
1.配置消息和事務日志持久保存的數據源，從JBoss安裝位置的docs\examples\jca目錄下拷貝到server\all\deploy目錄下，并修改其中的連接配置，這里使用OracleDS作為持久保存的數據源。注意：別忘了把Oracle的jdbc驅動程序拷貝到server\all\lib目錄下。
2.修改DestinationManager配置，刪除server\all\deploy-hasingleton\jms目錄下的hsqldb-jdbc2-service.xml文件，拷貝docs\examples\jms目錄下的oracle-jdbc2-service.xml到server\all\deploy-hasingleton目錄下，使用OracleDS作為DestinationManager的數據源。
3. 修改StateManager配置，將其中的數據源配置由
jboss.jca:service=DataSourceBinding,name=DefaultDS 改
jboss.jca:service=DataSourceBinding,name=OracleDS 4. 配置測試的Topic，在server\all\deploy-hasingleton\jms目錄下新建一個名為jbossweek-jms-service.xml文件，
<mbean code="org.jboss.mq.server.jmx.Topic" name="jboss.mq.destination:service=Topic,name=jbossweekTopic">
<depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends>
</mbean> 5. 創建node1的服務器配置，將server\all目錄復制一份改名為node1
6. 配置完成。
三、驗證
1. 分別以run –c all –b192.168.1.17和run –c node1–b192.168.1.148先后啟動all和node1配置。此時192.168.1.17為主節點，瀏覽http://192.168.1.17:8080/jmx-console/。打開JNDIView可以看到jbossweekTopic的JNDI名稱。此時192.168.1.17為主節點，瀏覽http://192.168.1.148:8080/jmx-console/。打開JNDIView就會發現沒有jbossweekTopic的JNDI名稱。
2. 關閉192.168.1.17上的all服務器，此時在192.168.1.148上的node服務器的控制臺上會出現如下信息：
13:11:13,921 INFO [TreeCache] viewAccepted(): [192.168.1.17:2292|2] [192.168.1.148:2327]
13:11:14,015 INFO [TreeCache] viewAccepted(): [192.168.1.17:2288|2] [192.168.1.148:2321]
13:11:14,218 INFO [DefaultPartition] New cluster view for partition DefaultPartition (id: 2, delta: -1) : [192.168.1.148:1099]
13:11:14,218 INFO [DefaultPartition] I am (192.168.1.148:1099) received members hipChanged event: 13:11:14,218 INFO [DefaultPartition] Dead members: 1 ([192.168.1.17:1099])
13:11:14,218 INFO [DefaultPartition] New Members : 0 ([])
13:11:14,218 INFO [DefaultPartition] All Members : 1 ([192.168.1.148:1099])
13:11:14,453 INFO [TreeCache] viewAccepted(): [192.168.1.17:2279|2] [192.168.1.148:2306]
13:11:16,218 INFO [TomcatDeployer] deploy, ctxPath=/jbossmq-httpil, warUrl=.../deploy-hasingleton/jms/jbossmq-httpil.sar/jbossmq-httpil.war/
13:11:17,406 INFO [jbossweekTopic] Bound to JNDI name: topic/jbossweekTopic
13:11:17,453 INFO [A] Bound to JNDI name: queue/A
13:11:17,453 INFO [B] Bound to JNDI name: queue/B
13:11:17,468 INFO [C] Bound to JNDI name: queue/C
13:11:17,468 INFO [D] Bound to JNDI name: queue/D
13:11:17,468 INFO [ex] Bound to JNDI name: queue/ex
13:11:17,484 INFO [testTopic] Bound to JNDI name: topic/testTopic
13:11:17,500 INFO [securedTopic] Bound to JNDI name: topic/securedTopic
13:11:17,500 INFO [testDurableTopic] Bound to JNDI name: topic/testDurableTopic
13:11:17,500 INFO [testQueue] Bound to JNDI name: queue/testQueue
13:11:17,562 INFO [UILServerILService] JBossMQ UIL service available at : /192.168.1.148:8093 13:11:17,609 INFO [DLQ] Bound to JNDI name: queue/DLQ
3. JMS集群的主節點自動切換到192.168.1.148上的node1節點，瀏覽http://192.168.1.148:8080/jmx-console/。打開JNDIView就會找到jbossweekTopic的JNDI名稱。
http://linliangyi2007.iteye.com/blog/316997http://docs.redhat.com/docs/zh-CN/JBoss_Enterprise_Application_Platform/5/html/JBoss_Messaging_User_Guide/index.html
找到你運行的instance的conf/jboss-service.xml, eg: $JBOSS_HOME/server/default/conf/jboss-service.xml
找到
mbean服務中，名字為 ServiceBindingManager 的，里面有個叫做ports-01的內容，打開這個注釋，就可以了。
如果你要運行多個，那么就需要有多個ServiceBindingManager ports-02，這是第三個，ports-03這是地四個，
這個文件，對應${jboss.home.url}/docs/examples/binding-manager/sample-bindings.xml里面的ports-01部分，ports-02部分，只不過需要在這里啟用，啟動的同時，$JBOSS_HOME/server/default/deploy/jboss-web.deployer/server.xml里面的就不起作用了。
提交訂票訂單的處理流程如下：
1）用戶通過瀏覽器訪問系統URL
2）界面集群F5將請求轉發至某一節點，通過比較用戶數據庫的內容進行身份鑒權。
3）鑒權成功后進入訂票，提交訂票訂單（查詢流程暫不討論）界面顯示請等待
4）訂票消息被發送至總線部件（接口可用web Service、RMI、甚至自定義協議都可以）
5）總線收到訂票消息、去Cache集群查詢相關車次
6）Cache根據自身維護的車次余票表，返回查詢結果，如果有余票，轉7）。如果無票了，則總線返回界面集群“沒票了”，界面提示用戶明天再試。
7）若有余票，則總線返回界面集群“正在出票，請等待”，并將訂票請求壓入隊列。且發消息至Cache，告訴CACHE將訂票請求加入隊列。
8）Cache收到總線隊列增加1個的消息，將自身維護的對應車次余票數減1個。
9）總線另一線程負責從隊列中取消息，并發送至出票部件。
10）出票部件產生訂票結果，并修改數據庫，發送“訂票成功”消息回總線。
11）總線將訂票成功消息直接回傳至界面集群。
12）用戶看到訂票結果。
