如何構(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è)方面引:火車出行是人們常用、 便捷的一種出行方式， 基于中國的人口多的情況，中國的火車出行人數(shù)非常龐大。中國鐵道部為了解決火車票訂票難、抵制“黃?！?、提高火車出行的安全性、提高訂票公平性等火車出行問題，先后推出了火車票實(shí)名制、網(wǎng)絡(luò)售票等業(yè)務(wù)，以方便旅客更便捷地使用火車作為交通工具出行。但目前所推出的網(wǎng)絡(luò)客票系統(tǒng)存在經(jīng)常性崩潰、 無法正常提供服務(wù)的情況， 究其根源，主要是因?yàn)槭褂帽鞠到y(tǒng)的人過多，超過系統(tǒng)的承載力所至，為了改善這些問題，從系統(tǒng)架構(gòu)方面著手是解決本系統(tǒng)的關(guān)鍵，構(gòu)建安全、穩(wěn)定、高 吞吐量的火車

2、票訂購系統(tǒng)也是迫在眉睫的事情?？推毕到y(tǒng)看起來如圖所示， 它包括柜臺(tái)訂票、 電話訂票、網(wǎng)絡(luò)訂票以及客票系統(tǒng)核心數(shù) 據(jù)庫等部分組成。本方案主要著眼于網(wǎng)絡(luò)訂票系統(tǒng)的架構(gòu)方案的討論，以期通過本方案可以實(shí)現(xiàn)一個(gè)超級(jí)、超大規(guī)模、可靈活擴(kuò)展的實(shí)時(shí)訂票交易系統(tǒng)?，F(xiàn)狀目前為鐵路網(wǎng)絡(luò)售票系統(tǒng)，周圍朋友均已經(jīng)紛紛注冊(cè)了信息在網(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)上紛紛對(duì)本系統(tǒng)產(chǎn)生了各種各樣的討論，有的說是系統(tǒng)設(shè)計(jì)問題、有的說是系統(tǒng)帶寬不足、有的說明

3、系統(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)行操作失敗并會(huì)重復(fù)訪問，因此如果系統(tǒng)運(yùn)行穩(wěn)定和可以正常服務(wù)后日訪問量將大幅減少（據(jù)A

4、leax不完全統(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)、高并發(fā)量分流方案、余票駁借、孤島計(jì)算模式等方 面提出一種全新的火車票訂

5、票系統(tǒng)解決方案。本方案假設(shè)與目標(biāo)假設(shè)：系統(tǒng)域名為： hcpxxxxxx.c n;原有客票系統(tǒng)已經(jīng)穩(wěn)定，可向網(wǎng)絡(luò)訂票提供正常的服務(wù)；不考慮柜臺(tái)與電話訂票。目標(biāo)：日最高訂票量500萬張（按目前網(wǎng)絡(luò)訂票系統(tǒng)工作18小時(shí)算，每秒處理訂單量為78 張）；高鋒時(shí)每秒處理訂票：5000張；日PV （頁面點(diǎn)擊量）：20億次；系統(tǒng)的基本業(yè)務(wù)流程系統(tǒng)余票信息查詢火車時(shí)刻查詢visitor火車票基本訂票流程是否有票沒:訂票成功？出票失結(jié)束visitor注冊(cè)、 錄系統(tǒng)前端WEB服務(wù)器機(jī)群原有客票系統(tǒng)（票庫輸入始發(fā)站、 車次、查詢余若其中“輸入乘客信息，訂票數(shù)量進(jìn)行訂票”的過程如下：向客票系統(tǒng)查詢實(shí)時(shí)余票 有余票一一

6、鎖訂所訂票數(shù)一一 出票，否則不成功。系統(tǒng)總體架構(gòu)為了實(shí)現(xiàn)超大訪問和實(shí)時(shí)處理系統(tǒng)，系統(tǒng)基本架構(gòu)如下圖所示:輸入乘客信息，訂票數(shù)量進(jìn)行訂票 k在線付款DNS解析visitor為=1三1) 口 1為應(yīng)用服務(wù)器機(jī)群DNS分流DNS分流是建立高吞吐量系統(tǒng)的第一步， 特別是在中國，由于南北互通問題，通過DNS 分流可以把南北用戶自動(dòng)分配到南北各自的網(wǎng)絡(luò)中。DNS分流已經(jīng)有成熟的技術(shù)和軟件， 因此這里不再詳細(xì)描述。DNS分流主要目的是把客流引入到不同的WEB前端服務(wù)器，通過 DNS分流可以實(shí)現(xiàn)客流的一級(jí)分流，比如分別在電信和網(wǎng)通放置5臺(tái)前端 WEB轉(zhuǎn)發(fā)（消息路由）服務(wù)器，則南北用戶將自動(dòng)由 DNS分流引入到

7、這些服務(wù)器中。一般大型的WEB系統(tǒng)不會(huì)在前端 WEB服務(wù)器中部署應(yīng)用，因?yàn)檫@樣是不可能達(dá)到高并發(fā)請(qǐng)求的，而是把前端WEB服務(wù)器作為消息路由服務(wù)器，把用戶請(qǐng)求按業(yè)務(wù)類型或是其它算法把客戶分流引入更多的服務(wù)器機(jī)群中，大概結(jié)構(gòu)如圖所示：前端WEB轉(zhuǎn)發(fā)（消息路由）服務(wù)器前端WEB服務(wù)器在高訪問量的系統(tǒng)中顯然不能作為應(yīng)用服務(wù)器，因此前端WEB應(yīng)該作為高速穿透性請(qǐng)求轉(zhuǎn)發(fā)器， 由這些轉(zhuǎn)發(fā)器把用戶的請(qǐng)求高速地分流到后端不同的應(yīng)用和服務(wù) 器集群中。WEB服務(wù)器不僅為請(qǐng)求分發(fā)系統(tǒng)，同時(shí)也是負(fù)載分發(fā)系統(tǒng)、業(yè)務(wù)分發(fā)系統(tǒng)，但 均不需要進(jìn)行軟件開發(fā)、只是部署而已。前端WEB服務(wù)器與DNS分流共同組成整個(gè)系統(tǒng)的分流、負(fù)載均

8、衡入口。把好動(dòng)靜態(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)中來，而并非僅僅是瀏覽呢？答案是肯定的。同時(shí)對(duì)于大訪問量的系統(tǒng)來說更應(yīng)該讓訪問者的計(jì)算機(jī)參與進(jìn)來。采用訪問者的計(jì)算機(jī)參與計(jì)算的模式，我把它叫“孤島計(jì)算模式”，它只負(fù)責(zé)當(dāng)前訪問者相關(guān)的計(jì)算，這樣就不會(huì)與服務(wù)器和其它訪問者構(gòu)成相互影響的關(guān)系。因此把一些互 不相關(guān)、計(jì)算量頻繁， 而數(shù)據(jù)量又不大的系統(tǒng)

9、安排給訪問者的計(jì)算機(jī)來計(jì)算是設(shè)計(jì)超大型訪 問量的系統(tǒng)的一個(gè)必然選擇，這樣可以充分利用訪問者計(jì)算機(jī)的閑置資源。那么在本系統(tǒng)中有哪些資源可以由訪問者的計(jì)算機(jī)來計(jì)算呢？顯然有很多， 比如時(shí)刻表 查詢、 站名查詢、轉(zhuǎn)程查詢、余票查詢的站名處理等信息。那么有人會(huì)問這不就需要把這些 數(shù)據(jù)都下載到客戶端嗎？答案是否定的， 系統(tǒng)應(yīng)該采用按需計(jì)算模式， 把用戶需要的數(shù)據(jù)下 載到客戶端即可。比如用要查詢K112次列車的信息，那么就不需要下載 T88次列車的信息。為了適應(yīng)客戶端高速計(jì)算， 處理掉服務(wù)器中的信息從數(shù)據(jù)庫中直接查詢也是必然的，大量信息可以生成 XML數(shù)據(jù)或是HTML靜態(tài)數(shù)據(jù)，比如時(shí)刻表、車站、車次等信息

10、均可以生 成靜態(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)行的。 基于火車票訂票系統(tǒng)的幾個(gè)基本流程，大概可以分以下幾個(gè)子業(yè)務(wù)系統(tǒng)：用戶注冊(cè)使用獨(dú)立的服務(wù)器和通道提交注冊(cè)信息和資料（比如：）。用戶登錄驗(yàn)證登錄驗(yàn)證是用戶進(jìn)入系統(tǒng)的第一道關(guān)， 因此它的訪問量也相對(duì)較大， 應(yīng)該使用獨(dú)立 的通道（同時(shí)需要采用負(fù)載均衡） ，比如使用： 專門處理用戶登錄。 余票信息查詢（ 比如使用： ）余票信息查詢應(yīng)該是整個(gè)

11、系統(tǒng)請(qǐng)求量最大的一個(gè)業(yè)務(wù)系統(tǒng)，目前系統(tǒng)采用30 分鐘更新余票信息，這樣做不僅不合理（不具有實(shí)時(shí)性） ，更增加了系統(tǒng)的壓力。建議采用 余票駁借 措施來處理系統(tǒng)， 所謂余票駁借， 即從總的客票系統(tǒng)中一次性借 入一定比例 （比如 20%）的票量到網(wǎng)絡(luò)訂票系統(tǒng)中， 并建立具有負(fù)載均衡的高速動(dòng)態(tài)緩存服 務(wù)器來查詢余票。采用余票駁借可以提供訂票的速度。比如某日票量為 500 萬張，由系統(tǒng)駁借 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í)地把成功出票的訂單更新到客

12、票系 統(tǒng)，這樣可以大大提供系統(tǒng)的訂單處理吞吐量， 同時(shí)也可以排除與客票系統(tǒng)高并發(fā)請(qǐng)求的壓 力風(fēng)險(xiǎn)。在經(jīng)過一定的時(shí)間或是客票系統(tǒng)售完后可以把駁借出來的票回收到客票系統(tǒng)中，或是網(wǎng)絡(luò)票售完后再從客票系統(tǒng)中駁借票。 這樣與客票系統(tǒng)的交互請(qǐng)求量將不再存在壓力。 所 以客票駁借是雙向的。 可以由專門的服務(wù)器來完成操作。 以達(dá)到網(wǎng)絡(luò)系統(tǒng)是真正的實(shí)時(shí)系統(tǒng)。駁借方式可以由專門的系統(tǒng)來管理策略并監(jiān)控各系統(tǒng)的售票情況，以便可以相互駁借。訂票系統(tǒng) （）在采用余票駁借的情況下， 訂票系統(tǒng)顯示格外輕松， 它的購票過程更加簡便， 不需 要在購票提交時(shí)進(jìn)入原有客票系統(tǒng)鎖定余票，而是僅需要駁借的這一部分中出票即可。那么所有網(wǎng)絡(luò)

13、出票的信息如何返回到鐵路系統(tǒng)中去呢？這變得很簡單，只需要更新駁借的票的身份信息即可 （即由誰訂了駁借的票） ，并且可由一兩臺(tái)服務(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)某訂單支付是否成功， 這也給訂票系統(tǒng)產(chǎn)生了壓力。那么對(duì)回饋系統(tǒng)構(gòu)建獨(dú)立架構(gòu)也是必不可少的，否則回饋不成功，則系統(tǒng)認(rèn)為沒有支付， 就產(chǎn)生了目前付了款， 但沒了票的情況。

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