建站
咨詢
售后
建站咨詢
新聞中心
非功能性要求
創(chuàng)新互聯(lián)專(zhuān)業(yè)為企業(yè)提供普洱網(wǎng)站建設(shè)、普洱做網(wǎng)站、普洱網(wǎng)站設(shè)計(jì)、普洱網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁(yè)設(shè)計(jì)與制作、普洱企業(yè)網(wǎng)站模板建站服務(wù)，十多年普洱做網(wǎng)站經(jīng)驗(yàn)，不只是建網(wǎng)站，更提供有價(jià)值的思路和整體網(wǎng)絡(luò)服務(wù)。
廢話不說(shuō)，這里先脫離系統(tǒng)的整體架構(gòu)，后續(xù)在不斷完善整體架構(gòu)，這里首先討論的是數(shù)據(jù)庫(kù)層面的設(shè)計(jì)，因?yàn)閷?duì)于整個(gè)架構(gòu)系統(tǒng)來(lái)說(shuō)，數(shù)據(jù)庫(kù)的設(shè)計(jì)是最為關(guān)鍵重要的，數(shù)據(jù)庫(kù)的設(shè)計(jì)好與壞，決定了整個(gè)系統(tǒng)的性能，可用性，擴(kuò)展性。在考慮數(shù)據(jù)庫(kù)的設(shè)計(jì)之前，我們可以先拋開(kāi)非業(yè)務(wù)功能的需求，先看看非功能性需求，主要包括
1 數(shù)據(jù)庫(kù)的類(lèi)型選擇
目前市場(chǎng)上數(shù)據(jù)庫(kù)主要有：關(guān)系型數(shù)據(jù)庫(kù)（Oracle,DB2,Mysql)，NOSQL類(lèi)型數(shù)據(jù)庫(kù)(MogonDB)，對(duì)象數(shù)據(jù)庫(kù)(不是很了解)，面向文檔的數(shù)據(jù)庫(kù)(apache couchBD),面向統(tǒng)計(jì)的數(shù)據(jù)庫(kù)(HBASE)
根據(jù)客票系統(tǒng)的類(lèi)型，應(yīng)該是屬于OLTP類(lèi)型的系統(tǒng)，但是考慮到商業(yè)上分析需求，也屬于OLAP型系統(tǒng)，由于本次討論OLTP系統(tǒng)的設(shè)計(jì)，優(yōu)先選擇Oracle。為啥，用的公司多，市場(chǎng)上相關(guān)的技術(shù)工程師多，DBA管理員多，安全性和性能都不錯(cuò)。就是有點(diǎn)貴，不過(guò)考慮到是鐵道部，完全忽略。對(duì)于部分客票系統(tǒng)非關(guān)鍵性業(yè)務(wù)也不重要的，這一部分?jǐn)?shù)據(jù)可以考慮使用Mysql。至于NOSQL，沒(méi)有用過(guò)，這個(gè)主要是面向web2.0的，對(duì)于事務(wù)要求高的系統(tǒng)，不太適合。
2 多數(shù)據(jù)中心
在金融行業(yè)，都必須部署多個(gè)數(shù)據(jù)中心，避免在一個(gè)數(shù)據(jù)庫(kù)機(jī)房故障之后，全部數(shù)據(jù)都不可用。比如假如某地地震，數(shù)據(jù)庫(kù)所在機(jī)房宕機(jī)了，如果這個(gè)時(shí)候檢票或者買(mǎi)票，就sb了，所以需要盡快恢復(fù)。這樣必須馬上啟動(dòng)另外一個(gè)數(shù)據(jù)庫(kù)機(jī)房配置。
除去災(zāi)備情況，考慮到鐵路售票系統(tǒng)數(shù)據(jù)庫(kù)的巨大訪問(wèn)量，2011年的鐵道部的旅客發(fā)送量---2011年全國(guó)鐵路運(yùn)輸目標(biāo):旅客發(fā)送量19億人次，根據(jù)這個(gè)，初略估計(jì)一下一年估計(jì)要20億張票，這個(gè)只是2011年的量，按照未來(lái)的幾年的增長(zhǎng)，按照目標(biāo)值100億人次估計(jì)，相當(dāng)于一天有2700W獨(dú)立UV，1億PV?？紤]到春節(jié)這個(gè)變態(tài)的高峰期，瞬間的并發(fā)量比平時(shí)會(huì)高上千倍。如果只在一個(gè)數(shù)據(jù)庫(kù)只有一臺(tái)，數(shù)據(jù)庫(kù)就會(huì)存在單點(diǎn)，一旦數(shù)據(jù)庫(kù)掛掉了，需要盡快的恢復(fù)。這個(gè)時(shí)候不太可能啟用災(zāi)備數(shù)據(jù)庫(kù)，因?yàn)闉?zāi)備是異地備份，備份數(shù)據(jù)庫(kù)同步數(shù)據(jù)比較慢（網(wǎng)絡(luò)延遲），所以必須必須在同一個(gè)城市在部署一套數(shù)據(jù)庫(kù)。這樣在單點(diǎn)數(shù)據(jù)庫(kù)故障的時(shí)候，可以馬上切到備份數(shù)據(jù)庫(kù)。
下面兩幅圖主要介紹異地災(zāi)備以及同城異機(jī)房備份的實(shí)現(xiàn)原理。
同城備份
數(shù)據(jù)一次寫(xiě)一份，日志寫(xiě)兩份。由于日志文件實(shí)時(shí)同步，A服務(wù)器寫(xiě)完B服務(wù)器的日志文件，B服務(wù)器馬上就寫(xiě)自己的數(shù)據(jù)文件。這樣不會(huì)丟失數(shù)據(jù)。當(dāng)A服務(wù)器故障，應(yīng)用馬上就可以切換到B服務(wù)器。不會(huì)存在單點(diǎn)故障。但是考慮特殊情況，北京地震，A，B機(jī)房同時(shí)故障，整個(gè)數(shù)據(jù)都丟失了。所以必須由異地災(zāi)備的數(shù)據(jù)中心。不過(guò)還有其他的方式，這里就不做敘述了?？傊且龊萌コ龁吸c(diǎn)。
異地備份
這個(gè)架構(gòu)和同城備份有一點(diǎn)區(qū)別，就是A服務(wù)器只會(huì)寫(xiě)A機(jī)房的日志文件，然后A異步同步日志到B機(jī)房的日志文件。這里面會(huì)有幾分鐘的網(wǎng)絡(luò)延遲。這里不實(shí)時(shí)寫(xiě)B(tài)機(jī)房的日志文件，主要是性能。如果實(shí)時(shí)寫(xiě)B(tài)機(jī)房的數(shù)據(jù)，一次更新操作，就會(huì)至少有一次網(wǎng)絡(luò)延遲（上海到北京的網(wǎng)絡(luò)傳輸時(shí)間）。會(huì)影響數(shù)據(jù)庫(kù)的性能。而同城市通過(guò)光纖連接，傳輸速率快，可以忽略網(wǎng)絡(luò)延遲。如果A機(jī)房故障（災(zāi)難性的故障，比如地震，機(jī)房被恐怖分子襲擊），就會(huì)丟失一部分?jǐn)?shù)據(jù)，丟失的數(shù)據(jù)就是網(wǎng)絡(luò)延遲同步的數(shù)據(jù)。對(duì)于購(gòu)票業(yè)務(wù)來(lái)說(shuō)，數(shù)據(jù)丟失幾分鐘的，是可以接受的，大不了我鐵道部虧一點(diǎn)，這幾分鐘丟失的數(shù)據(jù)我全部免票。也可以做一次好的營(yíng)銷(xiāo)。但是對(duì)于金融行業(yè)來(lái)說(shuō)，數(shù)據(jù)是不能丟失的，這里的異地備份就不符合金融業(yè)的要求。用性能換取可用性。就像atm取錢(qián)一樣，一次交易涉及幾分鐘。你的交易數(shù)據(jù)銀行至少會(huì)備份2份，一份同城的，一份異地的。
3 硬件配置
這一塊不是很熟悉，交給dba專(zhuān)業(yè)的人去做吧。小機(jī) + 存儲(chǔ)（SAS）。不過(guò)對(duì)于鐵道部有錢(qián)，上大機(jī)即可。不過(guò)我們還是按照互聯(lián)網(wǎng)方式去分析設(shè)計(jì)系統(tǒng)，使用普通的存儲(chǔ)以及服務(wù)器。
功能性分析
1 業(yè)務(wù)流程分析
先簡(jiǎn)單的了解一下購(gòu)票系統(tǒng)的業(yè)務(wù)流程：旅客到互聯(lián)網(wǎng)（也可能是其他渠道）登錄，根據(jù)出發(fā)日期，起始站，終點(diǎn)站查詢車(chē)票，確定車(chē)次和座位，預(yù)定車(chē)票，然后進(jìn)行支付，支付成功之后，發(fā)短信，之后客戶到線下去取票。一個(gè)簡(jiǎn)單的流程就結(jié)束了。
從上面的流程可以看出，整個(gè)業(yè)務(wù)流程中有幾個(gè)以下幾個(gè)實(shí)體以及實(shí)體的重要屬性信息
1 旅客信息：假設(shè)都是實(shí)名的，至少有三個(gè)重要信息 姓名，身份證，手機(jī)號(hào)
2 車(chē)次信息：車(chē)次，起始站，終點(diǎn)站，類(lèi)型，發(fā)車(chē)時(shí)間，到達(dá)時(shí)間
3 車(chē)次?？啃畔ⅲ很?chē)次，?？空荆_(dá)到時(shí)間，?？繒r(shí)間
4 余票信息：車(chē)次，起始站，終點(diǎn)站，發(fā)車(chē)日期，剩余座票，剩余臥鋪。
5 車(chē)票信息：車(chē)次，起始站，終點(diǎn)站，發(fā)車(chē)日期，購(gòu)票日期，旅客姓名，身份證，手機(jī)號(hào)，狀態(tài)，購(gòu)票渠道，支付日期
6 支付信息：金額，支付日期，支付銀行，支付金額，支付方式
7 短信信息：車(chē)票信息，驗(yàn)證碼，短信內(nèi)容
整個(gè)購(gòu)票過(guò)程包括以上幾個(gè)重要的實(shí)體，其他的幾個(gè)字段可以先不管。我們可以假設(shè)一下每一個(gè)實(shí)體的數(shù)據(jù)規(guī)模
| 實(shí)體 | 數(shù)據(jù)量 | 日增量 |
| 旅客信息 | 上限-中國(guó)人口數(shù) 16億 | 這個(gè)真不好估計(jì) |
| 車(chē)次信息 | 比較少，假設(shè)10萬(wàn) | 日增應(yīng)該也不會(huì)超過(guò)10 |
| 車(chē)次?？啃畔?/td> | 車(chē)次信息 ×200 == 200W | 日增應(yīng)該也不會(huì)超過(guò)100 |
| 車(chē)票信息 | 巨大，目前年增20億，未來(lái)年曾100億 | 自己換算一下，不過(guò)不會(huì)很平均，春節(jié)幾天會(huì)暴增 |
| 支付信息 | 和車(chē)票信息同數(shù)量級(jí) | 和車(chē)票信息一樣 |
| 短信信息 | 少于車(chē)票信息，畢竟只有網(wǎng)絡(luò)訂票才會(huì)有短信，線下購(gòu)票不會(huì)有 | 未知，假設(shè)100W |
| 余票信息 | 一年交易量 365×車(chē)次信息 == 5000W | 日增數(shù)據(jù)量 和 車(chē)次信息數(shù)量一致 假設(shè)10W |
從數(shù)據(jù)量來(lái)看 車(chē)票信息 > 支付信息 > 短信信息 > 余票信息 > 旅客信息 > 車(chē)次停靠信息 > 車(chē)次信息
從如此數(shù)據(jù)量來(lái)看，必須進(jìn)行分庫(kù)分表。所以分庫(kù)分表就在設(shè)計(jì)庫(kù)的時(shí)候就顯的非常重要。
2 簡(jiǎn)單分庫(kù)策略
旅客信息相關(guān)的信息單獨(dú)分在一個(gè)庫(kù)，這些數(shù)據(jù)相對(duì)來(lái)說(shuō)是讀多寫(xiě)少，并且可以大量進(jìn)行緩存，是基礎(chǔ)相數(shù)據(jù)。
車(chē)次相關(guān)的信息，比如車(chē)次，車(chē)次?？靠梢詥为?dú)放在一個(gè)標(biāo)里面，這個(gè)標(biāo)是保存原數(shù)據(jù)信息，數(shù)據(jù)量不大，數(shù)據(jù)完全可以緩存。可以考慮和余票庫(kù)放在一次。
剩下就是四大的實(shí)體信息，余票信息，車(chē)票信息，支付信息，短信通知信息，首先短信通知信息相對(duì)來(lái)說(shuō)比較通用的，可能未來(lái)很多業(yè)務(wù)都會(huì)涉及到短信通知，所以短信相關(guān)的信息放在一個(gè)庫(kù)
在剩下就是考慮業(yè)務(wù)上比較耦合的三個(gè)實(shí)體：余票，車(chē)票，支付。
余票查詢頻繁，每出一張票，就會(huì)更新余票數(shù)
車(chē)票數(shù)據(jù)量巨大，有查詢和更新需求
支付信息：?jiǎn)喂P查詢和更新需求
考慮到車(chē)票和支付信息在數(shù)據(jù)量級(jí)上遠(yuǎn)遠(yuǎn)高于余票信息，余票信息單獨(dú)一個(gè)庫(kù)，而車(chē)票信息和支付信息業(yè)務(wù)上差異比較大，也單獨(dú)分出來(lái)。
根據(jù)以上的分析，可以分出來(lái)5個(gè)邏輯庫(kù)：旅客庫(kù)，車(chē)票庫(kù)，短信庫(kù)，車(chē)次庫(kù)（車(chē)次信息，余票信息），支付庫(kù)。
繼續(xù)往下分析，在5個(gè)邏輯庫(kù)里面，由于旅客庫(kù)數(shù)據(jù)量有上線，只需要分配一個(gè)實(shí)體庫(kù)即可。 車(chē)次庫(kù)增長(zhǎng)有限，也暫時(shí)分配一個(gè)實(shí)體庫(kù)里面。而車(chē)庫(kù)票，支付庫(kù)，短信庫(kù)數(shù)據(jù)量比較大，分配一個(gè)實(shí)體庫(kù)顯然不夠。下面單獨(dú)分析這三個(gè)邏輯庫(kù)的分庫(kù)策略
3 車(chē)票庫(kù)分庫(kù)策略
對(duì)于車(chē)票信息的分庫(kù)策略，需要考慮到以下幾個(gè)因素
1. 功能需求
查詢需求：按照購(gòu)票日期 + 旅客信息 + 狀態(tài) 或者 旅客 + 發(fā)車(chē)日期 + 狀態(tài)
統(tǒng)計(jì)需求：按發(fā)車(chē)日期統(tǒng)計(jì)購(gòu)票總數(shù)量和金額 或者其他幾個(gè)維度
交易需求：創(chuàng)建車(chē)票信息，更新車(chē)票狀態(tài)，創(chuàng)建關(guān)聯(lián)支付信息
對(duì)賬需求：（假設(shè)不考慮退票需求）按照支付日期統(tǒng)計(jì)支付流水總金額 以及 統(tǒng)計(jì) 支付成功的車(chē)票信息總金額
2. 負(fù)載均衡
按照數(shù)據(jù)庫(kù)處理實(shí)時(shí)要求進(jìn)行分析，響應(yīng)要求高的請(qǐng)求和耗時(shí)類(lèi)請(qǐng)求分開(kāi)，優(yōu)先保證能夠賣(mài)出票，支付車(chē)票。同時(shí)不能所有的請(qǐng)求都指向一個(gè)庫(kù)。
3 高可用性
避免單點(diǎn)，否則購(gòu)票功能就不可用。所以數(shù)據(jù)庫(kù)至少有備份機(jī)制。
4 數(shù)據(jù)均勻
避免大多數(shù)據(jù)都在同一個(gè)庫(kù)，否則遇到大數(shù)據(jù)查詢數(shù)據(jù)庫(kù)負(fù)載會(huì)很高，進(jìn)而影響系統(tǒng)整體的可用性。因?yàn)榇蠖鄶?shù)請(qǐng)求都會(huì)排隊(duì)，導(dǎo)致系統(tǒng)資源耗盡。
5 可擴(kuò)展性
當(dāng)數(shù)據(jù)增長(zhǎng)過(guò)快時(shí)候，能夠很靈活的添加數(shù)據(jù)庫(kù)而整個(gè)應(yīng)用不需要做太大的修改
根據(jù)以上幾個(gè)因素考慮，每一張車(chē)票生成一個(gè)全局的唯一性id，根據(jù)id最后一位數(shù)字/N平均把數(shù)據(jù)分配到N個(gè)數(shù)據(jù)庫(kù)中，這樣每張車(chē)票庫(kù)最多可以分成10個(gè)庫(kù)，可擴(kuò)展性不強(qiáng)。也可以考慮一致性hash算法進(jìn)行分庫(kù)，但是這個(gè)比較復(fù)雜。還有一種方式就是隨機(jī)分庫(kù)，好處是可以無(wú)限擴(kuò)展數(shù)據(jù)庫(kù)，但是會(huì)給查詢帶來(lái)很大的影響?？紤]到查詢需求，太多的庫(kù)可能導(dǎo)致查詢復(fù)雜，甚至在有限時(shí)間內(nèi)無(wú)法查詢出來(lái)。這里采用最后數(shù)字/N的方式進(jìn)行分庫(kù)，N為數(shù)據(jù)庫(kù)的個(gè)數(shù)。在這個(gè)基礎(chǔ)上，在增加一個(gè)庫(kù)，就是歷史庫(kù)，暫時(shí)只需要一個(gè)即可，把完結(jié)的歷史數(shù)據(jù)遷移到這個(gè)庫(kù)，一個(gè)季度之前的數(shù)據(jù)不需要在進(jìn)行操作，一般只是查詢需求，就遷移到這個(gè)庫(kù)里面，減少交易庫(kù)的壓力。
這里分10個(gè)線上庫(kù)，一個(gè)歷史庫(kù)。一共11個(gè)庫(kù)。能夠支持年100億的交易規(guī)模。不過(guò)對(duì)于對(duì)賬的需求，可以考慮另外的方式來(lái)實(shí)現(xiàn)。這里以后在說(shuō)。
下面一幅圖展示了分庫(kù)的模型：
通過(guò)以上的分庫(kù)策略，如果某一個(gè)庫(kù)宕機(jī)了，會(huì)影響1/10的購(gòu)票用戶。
4 余票庫(kù)分庫(kù)策略
余票庫(kù)雖然數(shù)據(jù)量沒(méi)有車(chē)票庫(kù)數(shù)大，但是查詢和更新需求遠(yuǎn)比車(chē)票庫(kù)頻繁。而且是整個(gè)業(yè)務(wù)的關(guān)鍵路徑。在考慮這個(gè)庫(kù)的只需要保持一個(gè)月的數(shù)據(jù)即可，一個(gè)月前的數(shù)據(jù)可以遷移走，不需要所有的數(shù)據(jù)。而在春運(yùn)期間，這個(gè)庫(kù)的瞬間訪問(wèn)量會(huì)飆升，相當(dāng)于淘寶的秒殺，要求實(shí)時(shí)性比較高，所以不太可能讀寫(xiě)分離。綜合考慮，可以分為兩個(gè)庫(kù)， 線上庫(kù)和歷史庫(kù)。歷史庫(kù)用來(lái)做分析。這個(gè)后續(xù)是設(shè)計(jì)的重點(diǎn)。
5 支付庫(kù)分庫(kù)策略
支付信息和車(chē)票信息這兩個(gè)庫(kù)有點(diǎn)類(lèi)似，只是用戶查詢相對(duì)來(lái)說(shuō)比較少。這個(gè)支付庫(kù)分庫(kù)策略和車(chē)票庫(kù)的策略可以一樣。
6 短信庫(kù)分庫(kù)策略
由于短信通知是全站業(yè)務(wù)，這個(gè)完全可以獨(dú)立與購(gòu)票業(yè)務(wù)。消息量大，但非關(guān)鍵業(yè)務(wù)，非系統(tǒng)關(guān)鍵路徑，對(duì)實(shí)時(shí)行要求不高，所以簡(jiǎn)單分成兩個(gè)庫(kù)即可。
在分庫(kù)之后，數(shù)據(jù)一致性要求就會(huì)比較高，涉及到分布式事務(wù) ，后續(xù)會(huì)重點(diǎn)討論分布式事務(wù)的設(shè)計(jì)。
先寫(xiě)到這里吧，下一篇 會(huì)分析表結(jié)構(gòu)以及分表策略和索引。
分享題目：鐵道部新客票系統(tǒng)設(shè)計(jì)（一）
標(biāo)題鏈接：http://fisionsoft.com.cn/article/dpoceoh.html
