如何構(gòu)建安全、穩(wěn)定、高吞吐量的火車票網(wǎng)上售票系統(tǒng)

1、如果是你來構(gòu)建火車票訂票系統(tǒng)，你如何實現(xiàn)？關(guān)于構(gòu)建安全、穩(wěn)定、高吞吐量的火車票網(wǎng)絡售票系統(tǒng)幾個方面引：客票系統(tǒng)客票服務系統(tǒng)/數(shù)據(jù)庫/余票/訂票等柜臺訂票系統(tǒng)網(wǎng)絡訂票系統(tǒng)電話訂票系統(tǒng)火車票客票系統(tǒng)基本框圖火車出行是人們常用、便捷的一種出行方式，基于中國的人口多的情況，中國的火車出行人數(shù)非常龐大。中國鐵道部為了解決火車票訂票難、抵制“黃牛”、提高火車出行的安全性、提高訂票公平性等火車出行問題，先后推出了火車票實名制、網(wǎng)絡售票等業(yè)務，以方便旅客更便捷地使用火車作為交通工具出行。但目前所推出的網(wǎng)絡客票系統(tǒng)存在經(jīng)常性崩潰、無法正常提供服務的情況，究其根源，主要是因為使用本系統(tǒng)的人過多，超過系統(tǒng)的承載力所

2、至，為了改善這些問題，從系統(tǒng)架構(gòu)方面著手是解決本系統(tǒng)的關(guān)鍵，構(gòu)建安全、穩(wěn)定、高吞吐量的火車票訂購系統(tǒng)也是迫在眉睫的事情?？推毕到y(tǒng)看起來如圖所示，它包括柜臺訂票、電話訂票、網(wǎng)絡訂票以及客票系統(tǒng)核心數(shù)據(jù)庫等部分組成。本方案主要著眼于網(wǎng)絡訂票系統(tǒng)的架構(gòu)方案的討論，以期通過本方案可以實現(xiàn)一個超級、超大規(guī)模、可靈活擴展的實時訂票交易系統(tǒng)?，F(xiàn)狀目前為鐵路網(wǎng)絡售票系統(tǒng)，周圍朋友均已經(jīng)紛紛注冊了信息在網(wǎng)上進行訂票體驗，最壞的情況是一個朋友連續(xù)訂了兩天最終沒有訂票成功，系統(tǒng)不是提示忙就是提示超時（CDN緩存提示），系統(tǒng)幾乎處于癱瘓狀態(tài)。這不僅僅是帶寬不足，更是系統(tǒng)在架構(gòu)設計上的存在嚴重的不足。于是，在網(wǎng)上紛紛對

3、本系統(tǒng)產(chǎn)生了各種各樣的討論，有的說是系統(tǒng)設計問題、有的說是系統(tǒng)帶寬不足、有的說明系統(tǒng)設計時有失公平（競標）、有的說付了款卻沒了票、有的說是需要用“云計算技術(shù)”才能解決等等。不管怎么樣，重新架構(gòu)或進行重大調(diào)整是必然的。個人覺得云計算只不過是一種資源或信息服務方式，它也需要更好的系統(tǒng)的架構(gòu)和穩(wěn)健的系統(tǒng)才能提供這種服務方式，所以通過“云計算”并不能解決本系統(tǒng)的超大規(guī)模的訪問的承載，相反更應該從系統(tǒng)架構(gòu)方面來重拾系統(tǒng)的穩(wěn)健和可擴展性。目前最高日訪問量達14.09億次，最高日訂票量為166萬筆。顯示出本系統(tǒng)的高訪問量和事務密集。個人認為14億次訪問量與系統(tǒng)幾乎處于癱瘓狀態(tài)有關(guān)，因為用戶一旦進行操作失敗并

4、會重復訪問，因此如果系統(tǒng)運行穩(wěn)定和可以正常服務后日訪問量將大幅減少（據(jù)Aleax不完全統(tǒng)計7天訪問本系統(tǒng)的用戶是全球互聯(lián)網(wǎng)用戶的0.902%，按全球用戶為22億計算，大約為：0.1984億，所以每日的訪問獨立人數(shù)平均為0.1984億/7=285萬人，因此日訪問量14億更多的是來源于操作不成功的用戶重復訪問所至）。初步分析可以肯定，之所以無法正常提供服務和進行實時處理，其最可能的影響因素主要有：系統(tǒng)架構(gòu)不合理、余票查詢處理不當（此項業(yè)務訪問量是本系統(tǒng)最大的訪問量）、火車時刻查詢處理系統(tǒng)、訂票/支付系統(tǒng)集中（這是導致付款不成功的主要因素）、互聯(lián)網(wǎng)與鐵路網(wǎng)接入等問題。本文將從系統(tǒng)業(yè)務流程、系統(tǒng)架構(gòu)、

5、高并發(fā)量分流方案、余票駁借、孤島計算模式等方面提出一種全新的火車票訂票系統(tǒng)解決方案。本方案假設與目標假設：系統(tǒng)域名為：；原有客票系統(tǒng)已經(jīng)穩(wěn)定，可向網(wǎng)絡訂票提供正常的服務；不考慮柜臺與電話訂票。目標：日最高訂票量500萬張（按目前網(wǎng)絡訂票系統(tǒng)工作18小時算，每秒處理訂單量為78張）；高鋒時每秒處理訂票：5000張；日PV（頁面點擊量）：20億次；系統(tǒng)的基本業(yè)務流程系統(tǒng)余票信息查詢visitor輸入車次、始終站、時間等信息查詢火車時刻查詢visitor輸入車次、始終站、時間等信息查詢火車票基本訂票流程visitor注冊、登錄系統(tǒng)結(jié)束是否有票輸入乘客信息，訂票數(shù)量進行訂票訂票成功？在線付款輸入始發(fā)站

6、、車次、查詢余票沒有余票出票失敗其中“輸入乘客信息，訂票數(shù)量進行訂票”的過程如下：向客票系統(tǒng)查詢實時余票若有余票鎖訂所訂票數(shù)出票，否則不成功。系統(tǒng)總體架構(gòu)為了實現(xiàn)超大訪問和實時處理系統(tǒng)，系統(tǒng)基本架構(gòu)如下圖所示：visitor前端WEB服務器機群應用服務器機群原有客票系統(tǒng)(票庫)DNS解析DNS分流DNS分流是建立高吞吐量系統(tǒng)的第一步，特別是在中國，由于南北互通問題，通過DNS分流可以把南北用戶自動分配到南北各自的網(wǎng)絡中。DNS分流已經(jīng)有成熟的技術(shù)和軟件，因此這里不再詳細描述。DNS分流主要目的是把客流引入到不同的WEB前端服務器，通過DNS分流可以實現(xiàn)客流的一級分流，比如分別在電信和網(wǎng)通放置5

7、臺前端WEB轉(zhuǎn)發(fā)（消息路由）服務器，則南北用戶將自動由DNS分流引入到這些服務器中。一般大型的WEB系統(tǒng)不會在前端WEB服務器中部署應用，因為這樣是不可能達到高并發(fā)請求的，而是把前端WEB服務器作為消息路由服務器，把用戶請求按業(yè)務類型或是其它算法把客戶分流引入更多的服務器機群中，大概結(jié)構(gòu)如圖所示：visitorsvisitorsvisitorsvisitorsvisitorsvisitorsWEB S1WEB S2WEB S3WEB SN前端WEB消息轉(zhuǎn)發(fā)服務器DNS分流解析DNS分流解析DNS分流，實現(xiàn)請求分流應用服務器池/機群前端WEB轉(zhuǎn)發(fā)（消息路由）服務器前端WEB服務器在高訪問量的系統(tǒng)

8、中顯然不能作為應用服務器，因此前端WEB應該作為高速穿透性請求轉(zhuǎn)發(fā)器，由這些轉(zhuǎn)發(fā)器把用戶的請求高速地分流到后端不同的應用和服務器集群中。WEB服務器不僅為請求分發(fā)系統(tǒng)，同時也是負載分發(fā)系統(tǒng)、業(yè)務分發(fā)系統(tǒng)，但均不需要進行軟件開發(fā)、只是部署而已。前端WEB服務器與DNS分流共同組成整個系統(tǒng)的分流、負載均衡入口。把好動靜態(tài)數(shù)據(jù)關(guān)、采用孤島計算模式大型內(nèi)容發(fā)布系統(tǒng)、商品系統(tǒng)無不把信息生成靜態(tài)HTML或靜態(tài)數(shù)據(jù)，這樣可以極大地緩解后端應用服務器和數(shù)據(jù)庫的壓力?？梢赃@樣設想，有多少人訪問系統(tǒng)就有多少計算機參與到整個系統(tǒng)的計算。顯然服務器端占了計算的主要部分，那么是否可以讓這些使用者的計算機也參與到整個系統(tǒng)

9、中來，而并非僅僅是瀏覽呢？答案是肯定的。同時對于大訪問量的系統(tǒng)來說更應該讓訪問者的計算機參與進來。采用訪問者的計算機參與計算的模式，我把它叫“孤島計算模式”，它只負責當前訪問者相關(guān)的計算，這樣就不會與服務器和其它訪問者構(gòu)成相互影響的關(guān)系。因此把一些互不相關(guān)、計算量頻繁，而數(shù)據(jù)量又不大的系統(tǒng)安排給訪問者的計算機來計算是設計超大型訪問量的系統(tǒng)的一個必然選擇，這樣可以充分利用訪問者計算機的閑置資源。那么在本系統(tǒng)中有哪些資源可以由訪問者的計算機來計算呢？顯然有很多，比如時刻表查詢、站名查詢、轉(zhuǎn)程查詢、余票查詢的站名處理等信息。那么有人會問這不就需要把這些數(shù)據(jù)都下載到客戶端嗎？答案是否定的，系統(tǒng)應該采用

10、按需計算模式，把用戶需要的數(shù)據(jù)下載到客戶端即可。比如用要查詢K112次列車的信息，那么就不需要下載T88次列車的信息。為了適應客戶端高速計算，處理掉服務器中的信息從數(shù)據(jù)庫中直接查詢也是必然的，大量信息可以生成XML數(shù)據(jù)或是HTML靜態(tài)數(shù)據(jù)，比如時刻表、車站、車次等信息均可以生成靜態(tài)的XML數(shù)據(jù)，這樣可以把服務器的CPU時間安排給更需要的業(yè)務系統(tǒng)或是分拆給不同的業(yè)務系統(tǒng)。同時，通過大量資源的靜態(tài)化處理和分離式計算，可以提高CDN的效率。業(yè)務系統(tǒng)分流除了系統(tǒng)整體部署和硬件架構(gòu)外，系統(tǒng)的業(yè)務分開處理，也是一個大型系統(tǒng)必須進行的?；诨疖嚻庇喥毕到y(tǒng)的幾個基本流程，大概可以分以下幾個子業(yè)務系統(tǒng)：用戶注冊

11、使用獨立的服務器和通道提交注冊信息和資料（比如：）。用戶登錄驗證登錄驗證是用戶進入系統(tǒng)的第一道關(guān)，因此它的訪問量也相對較大，應該使用獨立的通道（同時需要采用負載均衡），比如使用： 專門處理用戶登錄。余票信息查詢（比如使用：）余票信息查詢應該是整個系統(tǒng)請求量最大的一個業(yè)務系統(tǒng)，目前系統(tǒng)采用30分鐘更新余票信息，這樣做不僅不合理（不具有實時性），更增加了系統(tǒng)的壓力。建議采用余票駁借措施來處理系統(tǒng)，所謂余票駁借，即從總的客票系統(tǒng)中一次性借入一定比例（比如20%）的票量到網(wǎng)絡訂票系統(tǒng)中，并建立具有負載均衡的高速動態(tài)緩存服務器來查詢余票。采用余票駁借可以提供訂票的速度。比如某日票量為500萬張，由系統(tǒng)駁

12、借20%即100萬張進入網(wǎng)絡售票系統(tǒng)，那么這100萬張在客票系統(tǒng)看來已經(jīng)被訂出。因此在網(wǎng)絡售票系統(tǒng)中產(chǎn)生的訂單和出票不需要再與客票系統(tǒng)進行交互，而是由后端的處理系統(tǒng)定時或是實時地把成功出票的訂單更新到客票系統(tǒng)，這樣可以大大提供系統(tǒng)的訂單處理吞吐量，同時也可以排除與客票系統(tǒng)高并發(fā)請求的壓力風險。在經(jīng)過一定的時間或是客票系統(tǒng)售完后可以把駁借出來的票回收到客票系統(tǒng)中，或是網(wǎng)絡票售完后再從客票系統(tǒng)中駁借票。這樣與客票系統(tǒng)的交互請求量將不再存在壓力。所以客票駁借是雙向的。可以由專門的服務器來完成操作。以達到網(wǎng)絡系統(tǒng)是真正的實時系統(tǒng)。駁借方式可以由專門的系統(tǒng)來管理策略并監(jiān)控各系統(tǒng)的售票情況，以便可以相互駁

13、借。訂票系統(tǒng)()在采用余票駁借的情況下，訂票系統(tǒng)顯示格外輕松，它的購票過程更加簡便，不需要在購票提交時進入原有客票系統(tǒng)鎖定余票，而是僅需要駁借的這一部分中出票即可。那么所有網(wǎng)絡出票的信息如何返回到鐵路系統(tǒng)中去呢？這變得很簡單，只需要更新駁借的票的身份信息即可（即由誰訂了駁借的票），并且可由一兩臺服務器在后端進行處理。由于訂票量大，所以訂票系統(tǒng)需要采用分布式架構(gòu)和車次分流架構(gòu)（車次分流可參考相關(guān)章節(jié)）。分布式架構(gòu)可采用形式較多，比如按車次分流后各自獨立數(shù)據(jù)庫，在訂票產(chǎn)生后由后端的服務器來歸并計算訂票情況。支付回饋系統(tǒng)()支付系統(tǒng)本應該是一個最簡單的系統(tǒng)，但是由于支付后銀行的系統(tǒng)需要回饋訂票系統(tǒng)某

14、訂單支付是否成功，這也給訂票系統(tǒng)產(chǎn)生了壓力。那么對回饋系統(tǒng)構(gòu)建獨立架構(gòu)也是必不可少的，否則回饋不成功，則系統(tǒng)認為沒有支付，就產(chǎn)生了目前付了款，但沒了票的情況。支付流程大概如下圖所示，顯然現(xiàn)有系統(tǒng)在支付回饋中出了問題，歸根到底還是訂票系統(tǒng)崩潰或是無法響應所至。但相對于整個系統(tǒng)來說支付回饋的請求量遠少于余票查詢系統(tǒng)的訪問量。visitors訂票系統(tǒng)銀行系統(tǒng)支付支付回饋短信確認系統(tǒng)短信確認系統(tǒng)由訂票系統(tǒng)使用，因此不存在請求上太大的壓力，但是構(gòu)建短信隊列是必要的。并且實時性要求并不高。以下信息并非高訪問量的系統(tǒng)可以構(gòu)建完全的靜態(tài)和客戶端計算模式的系統(tǒng)。火車時刻查詢正晚點查詢客票代售點查詢鐵路轉(zhuǎn)程查詢火車車次分流由于火車車次間相對獨立性，因此使用基于車次進行分流是一種可行的措施。比如：T1T1000采用A服務器、D1D100采用B服務器，這樣來進行分流。由客戶端（用戶計算機）來決定使用哪一個服務器提供服務。這樣在訂票時對服務器的壓力可以大大減少，同時可以無限制的擴展服務