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

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

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

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

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

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

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

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

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

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

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

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

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

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

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