非功能性要求

廢話不說，這里先脫離系統(tǒng)的整體架構(gòu)，后續(xù)在不斷完善整體架構(gòu)，這里首先討論的是數(shù)據(jù)庫層面的設(shè)計(jì)，因?yàn)閷τ谡麄€(gè)架構(gòu)系統(tǒng)來說，數(shù)據(jù)庫的設(shè)計(jì)是最為關(guān)鍵重要的，數(shù)據(jù)庫的設(shè)計(jì)好與壞，決定了整個(gè)系統(tǒng)的性能，可用性，擴(kuò)展性。在考慮數(shù)據(jù)庫的設(shè)計(jì)之前，我們可以先拋開非業(yè)務(wù)功能的需求，先看看非功能性需求，主要包括

1 數(shù)據(jù)庫的類型選擇

目前市場上數(shù)據(jù)庫主要有：關(guān)系型數(shù)據(jù)庫（Oracle,DB2,Mysql)，NOSQL類型數(shù)據(jù)庫(MogonDB)，對象數(shù)據(jù)庫(不是很了解)，面向文檔的數(shù)據(jù)庫(apache couchBD),面向統(tǒng)計(jì)的數(shù)據(jù)庫(HBASE)

根據(jù)客票系統(tǒng)的類型，應(yīng)該是屬于OLTP類型的系統(tǒng)，但是考慮到商業(yè)上分析需求，也屬于OLAP型系統(tǒng)，由于本次討論OLTP系統(tǒng)的設(shè)計(jì)，優(yōu)先選擇Oracle。為啥，用的公司多，市場上相關(guān)的技術(shù)工程師多，DBA管理員多，安全性和性能都不錯(cuò)。就是有點(diǎn)貴，不過考慮到是鐵道部，完全忽略。對于部分客票系統(tǒng)非關(guān)鍵性業(yè)務(wù)也不重要的，這一部分?jǐn)?shù)據(jù)可以考慮使用Mysql。至于NOSQL，沒有用過，這個(gè)主要是面向web2.0的，對于事務(wù)要求高的系統(tǒng)，不太適合。

2 多數(shù)據(jù)中心

在金融行業(yè)，都必須部署多個(gè)數(shù)據(jù)中心，避免在一個(gè)數(shù)據(jù)庫機(jī)房故障之后，全部數(shù)據(jù)都不可用。比如假如某地地震，數(shù)據(jù)庫所在機(jī)房宕機(jī)了，如果這個(gè)時(shí)候檢票或者買票，就sb了，所以需要盡快恢復(fù)。這樣必須馬上啟動(dòng)另外一個(gè)數(shù)據(jù)庫機(jī)房配置。

除去災(zāi)備情況，考慮到鐵路售票系統(tǒng)數(shù)據(jù)庫的巨大訪問量，2011年的鐵道部的旅客發(fā)送量---2011年全國鐵路運(yùn)輸目標(biāo):旅客發(fā)送量19億人次，根據(jù)這個(gè)，初略估計(jì)一下一年估計(jì)要20億張票，這個(gè)只是2011年的量，按照未來的幾年的增長，按照目標(biāo)值100億人次估計(jì)，相當(dāng)于一天有2700W獨(dú)立UV，1億PV。考慮到春節(jié)這個(gè)變態(tài)的高峰期，瞬間的并發(fā)量比平時(shí)會(huì)高上千倍。如果只在一個(gè)數(shù)據(jù)庫只有一臺(tái)，數(shù)據(jù)庫就會(huì)存在單點(diǎn)，一旦數(shù)據(jù)庫掛掉了，需要盡快的恢復(fù)。這個(gè)時(shí)候不太可能啟用災(zāi)備數(shù)據(jù)庫，因?yàn)闉?zāi)備是異地備份，備份數(shù)據(jù)庫同步數(shù)據(jù)比較慢（網(wǎng)絡(luò)延遲），所以必須必須在同一個(gè)城市在部署一套數(shù)據(jù)庫。這樣在單點(diǎn)數(shù)據(jù)庫故障的時(shí)候，可以馬上切到備份數(shù)據(jù)庫。

下面兩幅圖主要介紹異地災(zāi)備以及同城異機(jī)房備份的實(shí)現(xiàn)原理。

同城備份

　　 數(shù)據(jù)一次寫一份，日志寫兩份。由于日志文件實(shí)時(shí)同步，A服務(wù)器寫完B服務(wù)器的日志文件，B服務(wù)器馬上就寫自己的數(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ù)中心。不過還有其他的方式，這里就不做敘述了。總之是要做好去除單點(diǎn)。

異地備份

　　　這個(gè)架構(gòu)和同城備份有一點(diǎn)區(qū)別，就是A服務(wù)器只會(huì)寫A機(jī)房的日志文件，然后A異步同步日志到B機(jī)房的日志文件。這里面會(huì)有幾分鐘的網(wǎng)絡(luò)延遲。這里不實(shí)時(shí)寫B(tài)機(jī)房的日志文件，主要是性能。如果實(shí)時(shí)寫B(tài)機(jī)房的數(shù)據(jù)，一次更新操作，就會(huì)至少有一次網(wǎng)絡(luò)延遲（上海到北京的網(wǎng)絡(luò)傳輸時(shí)間）。會(huì)影響數(shù)據(jù)庫的性能。而同城市通過光纖連接，傳輸速率快，可以忽略網(wǎng)絡(luò)延遲。如果A機(jī)房故障（災(zāi)難性的故障，比如地震，機(jī)房被恐怖分子襲擊），就會(huì)丟失一部分?jǐn)?shù)據(jù)，丟失的數(shù)據(jù)就是網(wǎng)絡(luò)延遲同步的數(shù)據(jù)。對于購票業(yè)務(wù)來說，數(shù)據(jù)丟失幾分鐘的，是可以接受的，大不了我鐵道部虧一點(diǎn)，這幾分鐘丟失的數(shù)據(jù)我全部免票。也可以做一次好的營銷。但是對于金融行業(yè)來說，數(shù)據(jù)是不能丟失的，這里的異地備份就不符合金融業(yè)的要求。用性能換取可用性。就像atm取錢一樣，一次交易涉及幾分鐘。你的交易數(shù)據(jù)銀行至少會(huì)備份2份，一份同城的，一份異地的。

3 硬件配置

這一塊不是很熟悉，交給dba專業(yè)的人去做吧。小機(jī) + 存儲(chǔ)（SAS）。不過對于鐵道部有錢，上大機(jī)即可。不過我們還是按照互聯(lián)網(wǎng)方式去分析設(shè)計(jì)系統(tǒng)，使用普通的存儲(chǔ)以及服務(wù)器。

功能性分析

1 業(yè)務(wù)流程分析

先簡單的了解一下購票系統(tǒng)的業(yè)務(wù)流程：旅客到互聯(lián)網(wǎng)（也可能是其他渠道）登錄，根據(jù)出發(fā)日期，起始站，終點(diǎn)站查詢車票，確定車次和座位，預(yù)定車票，然后進(jìn)行支付，支付成功之后，發(fā)短信，之后客戶到線下去取票。一個(gè)簡單的流程就結(jié)束了。

從上面的流程可以看出，整個(gè)業(yè)務(wù)流程中有幾個(gè)以下幾個(gè)實(shí)體以及實(shí)體的重要屬性信息

1 旅客信息：假設(shè)都是實(shí)名的，至少有三個(gè)重要信息 姓名，身份證，手機(jī)號(hào)

2 車次信息：車次，起始站，終點(diǎn)站，類型，發(fā)車時(shí)間，到達(dá)時(shí)間

3 車次停靠信息：車次，停靠站，達(dá)到時(shí)間，停靠時(shí)間

4 余票信息：車次，起始站，終點(diǎn)站，發(fā)車日期，剩余座票，剩余臥鋪。。。

5 車票信息：車次，起始站，終點(diǎn)站，發(fā)車日期，購票日期，旅客姓名，身份證，手機(jī)號(hào)，狀態(tài)，購票渠道，支付日期

6 支付信息：金額，支付日期，支付銀行，支付金額，支付方式

7 短信信息：車票信息，驗(yàn)證碼，短信內(nèi)容

整個(gè)購票過程包括以上幾個(gè)重要的實(shí)體，其他的幾個(gè)字段可以先不管。我們可以假設(shè)一下每一個(gè)實(shí)體的數(shù)據(jù)規(guī)模

從數(shù)據(jù)量來看 車票信息 > 支付信息 > 短信信息 > 余票信息 > 旅客信息 > 車次停靠信息 > 車次信息

從如此數(shù)據(jù)量來看，必須進(jìn)行分庫分表。所以分庫分表就在設(shè)計(jì)庫的時(shí)候就顯的非常重要。

2 簡單分庫策略

旅客信息相關(guān)的信息單獨(dú)分在一個(gè)庫，這些數(shù)據(jù)相對來說是讀多寫少，并且可以大量進(jìn)行緩存，是基礎(chǔ)相數(shù)據(jù)。

車次相關(guān)的信息，比如車次，車次停靠可以單獨(dú)放在一個(gè)標(biāo)里面，這個(gè)標(biāo)是保存原數(shù)據(jù)信息，數(shù)據(jù)量不大，數(shù)據(jù)完全可以緩存。可以考慮和余票庫放在一次。

剩下就是四大的實(shí)體信息，余票信息，車票信息，支付信息，短信通知信息，首先短信通知信息相對來說比較通用的，可能未來很多業(yè)務(wù)都會(huì)涉及到短信通知，所以短信相關(guān)的信息放在一個(gè)庫

在剩下就是考慮業(yè)務(wù)上比較耦合的三個(gè)實(shí)體：余票，車票，支付。

余票查詢頻繁，每出一張票，就會(huì)更新余票數(shù)

車票數(shù)據(jù)量巨大，有查詢和更新需求

支付信息：單筆查詢和更新需求

考慮到車票和支付信息在數(shù)據(jù)量級(jí)上遠(yuǎn)遠(yuǎn)高于余票信息，余票信息單獨(dú)一個(gè)庫，而車票信息和支付信息業(yè)務(wù)上差異比較大，也單獨(dú)分出來。

根據(jù)以上的分析，可以分出來5個(gè)邏輯庫：旅客庫，車票庫，短信庫，車次庫（車次信息，余票信息），支付庫。

繼續(xù)往下分析，在5個(gè)邏輯庫里面，由于旅客庫數(shù)據(jù)量有上線，只需要分配一個(gè)實(shí)體庫即可。 車次庫增長有限，也暫時(shí)分配一個(gè)實(shí)體庫里面。而車庫票，支付庫，短信庫數(shù)據(jù)量比較大，分配一個(gè)實(shí)體庫顯然不夠。下面單獨(dú)分析這三個(gè)邏輯庫的分庫策略

3 車票庫分庫策略

對于車票信息的分庫策略，需要考慮到以下幾個(gè)因素

 1. 功能需求

　　　查詢需求：按照購票日期 + 旅客信息 + 狀態(tài) 或者 旅客 +  發(fā)車日期 + 狀態(tài) 

　　　統(tǒng)計(jì)需求：按發(fā)車日期統(tǒng)計(jì)購票總數(shù)量和金額 或者其他幾個(gè)維度

　　　交易需求：創(chuàng)建車票信息，更新車票狀態(tài)，創(chuàng)建關(guān)聯(lián)支付信息

　　　對賬需求：（假設(shè)不考慮退票需求）按照支付日期統(tǒng)計(jì)支付流水總金額 以及 統(tǒng)計(jì) 支付成功的車票信息總金額

2. 負(fù)載均衡

　　   按照數(shù)據(jù)庫處理實(shí)時(shí)要求進(jìn)行分析，響應(yīng)要求高的請求和耗時(shí)類請求分開，優(yōu)先保證能夠賣出票，支付車票。同時(shí)不能所有的請求都指向一個(gè)庫。

3  高可用性

避免單點(diǎn)，否則購票功能就不可用。所以數(shù)據(jù)庫至少有備份機(jī)制。

4 數(shù)據(jù)均勻

避免大多數(shù)據(jù)都在同一個(gè)庫，否則遇到大數(shù)據(jù)查詢數(shù)據(jù)庫負(fù)載會(huì)很高，進(jìn)而影響系統(tǒng)整體的可用性。因?yàn)榇蠖鄶?shù)請求都會(huì)排隊(duì)，導(dǎo)致系統(tǒng)資源耗盡。

　　5 可擴(kuò)展性

　　　當(dāng)數(shù)據(jù)增長過快時(shí)候，能夠很靈活的添加數(shù)據(jù)庫而整個(gè)應(yīng)用不需要做太大的修改

根據(jù)以上幾個(gè)因素考慮，每一張車票生成一個(gè)全局的唯一性id，根據(jù)id最后一位數(shù)字/N平均把數(shù)據(jù)分配到N個(gè)數(shù)據(jù)庫中，這樣每張車票庫最多可以分成10個(gè)庫，可擴(kuò)展性不強(qiáng)。也可以考慮一致性hash算法進(jìn)行分庫，但是這個(gè)比較復(fù)雜。還有一種方式就是隨機(jī)分庫，好處是可以無限擴(kuò)展數(shù)據(jù)庫，但是會(huì)給查詢帶來很大的影響。考慮到查詢需求，太多的庫可能導(dǎo)致查詢復(fù)雜，甚至在有限時(shí)間內(nèi)無法查詢出來。這里采用最后數(shù)字/N的方式進(jìn)行分庫，N為數(shù)據(jù)庫的個(gè)數(shù)。在這個(gè)基礎(chǔ)上，在增加一個(gè)庫，就是歷史庫，暫時(shí)只需要一個(gè)即可，把完結(jié)的歷史數(shù)據(jù)遷移到這個(gè)庫，一個(gè)季度之前的數(shù)據(jù)不需要在進(jìn)行操作，一般只是查詢需求，就遷移到這個(gè)庫里面，減少交易庫的壓力。

這里分10個(gè)線上庫，一個(gè)歷史庫。一共11個(gè)庫。能夠支持年100億的交易規(guī)模。不過對于對賬的需求，可以考慮另外的方式來實(shí)現(xiàn)。這里以后在說。

下面一幅圖展示了分庫的模型：

通過以上的分庫策略，如果某一個(gè)庫宕機(jī)了，會(huì)影響1/10的購票用戶。

4 余票庫分庫策略

余票庫雖然數(shù)據(jù)量沒有車票庫數(shù)大，但是查詢和更新需求遠(yuǎn)比車票庫頻繁。而且是整個(gè)業(yè)務(wù)的關(guān)鍵路徑。在考慮這個(gè)庫的只需要保持一個(gè)月的數(shù)據(jù)即可，一個(gè)月前的數(shù)據(jù)可以遷移走，不需要所有的數(shù)據(jù)。而在春運(yùn)期間，這個(gè)庫的瞬間訪問量會(huì)飆升，相當(dāng)于淘寶的秒殺，要求實(shí)時(shí)性比較高，所以不太可能讀寫分離。綜合考慮，可以分為兩個(gè)庫， 線上庫和歷史庫。歷史庫用來做分析。這個(gè)后續(xù)是設(shè)計(jì)的重點(diǎn)。

5 支付庫分庫策略

支付信息和車票信息這兩個(gè)庫有點(diǎn)類似，只是用戶查詢相對來說比較少。這個(gè)支付庫分庫策略和車票庫的策略可以一樣。

6 短信庫分庫策略

由于短信通知是全站業(yè)務(wù)，這個(gè)完全可以獨(dú)立與購票業(yè)務(wù)。消息量大，但非關(guān)鍵業(yè)務(wù)，非系統(tǒng)關(guān)鍵路徑，對實(shí)時(shí)行要求不高，所以簡單分成兩個(gè)庫即可。

在分庫之后，數(shù)據(jù)一致性要求就會(huì)比較高，涉及到分布式事務(wù) ，后續(xù)會(huì)重點(diǎn)討論分布式事務(wù)的設(shè)計(jì)。

先寫到這里吧，下一篇 會(huì)分析表結(jié)構(gòu)以及分表策略和索引。

原文鏈接：http://www.cnblogs.com/aigongsi/archive/2012/09/17/2683656.html

【編輯推薦】

1. ASP.NET Web開發(fā)框架項(xiàng)目介紹
2. YQBlog .NET MVC3博客系統(tǒng)之用戶系統(tǒng)實(shí)戰(zhàn)
3. ASP.NET Cache的一些總結(jié)
4. ASP.NET中常用的幾種身份驗(yàn)證方式
5. 各自為政：ASP.NET實(shí)現(xiàn)團(tuán)隊(duì)分工的思考