非功能性要求

廢話不說，這里先脫離系統(tǒng)的整體架構(gòu)，后續(xù)在不斷完善整體架構(gòu)，這里首先討論的是數(shù)據(jù)庫層面的設(shè)計，因為對于整個架構(gòu)系統(tǒng)來說，數(shù)據(jù)庫的設(shè)計是最為關(guān)鍵重要的，數(shù)據(jù)庫的設(shè)計好與壞，決定了整個系統(tǒng)的性能，可用性，擴展性。在考慮數(shù)據(jù)庫的設(shè)計之前，我們可以先拋開非業(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)計的數(shù)據(jù)庫(HBASE)

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

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

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

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

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

同城備份

　　 數(shù)據(jù)一次寫一份，日志寫兩份。由于日志文件實時同步，A服務(wù)器寫完B服務(wù)器的日志文件，B服務(wù)器馬上就寫自己的數(shù)據(jù)文件。這樣不會丟失數(shù)據(jù)。當A服務(wù)器故障，應(yīng)用馬上就可以切換到B服務(wù)器。不會存在單點故障。但是考慮特殊情況，北京地震，A，B機房同時故障，整個數(shù)據(jù)都丟失了。所以必須由異地災(zāi)備的數(shù)據(jù)中心。不過還有其他的方式，這里就不做敘述了?？傊且龊萌コ龁吸c。

異地備份

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

3 硬件配置

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

功能性分析

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

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

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

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

2 車次信息：車次，起始站，終點站，類型，發(fā)車時間，到達時間

3 車次?？啃畔ⅲ很嚧?，?？空?，達到時間，?？繒r間

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

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

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

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

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

從數(shù)據(jù)量來看 車票信息 > 支付信息 > 短信信息 > 余票信息 > 旅客信息 > 車次?？啃畔?> 車次信息

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

2 簡單分庫策略

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

車次相關(guān)的信息，比如車次，車次停靠可以單獨放在一個標里面，這個標是保存原數(shù)據(jù)信息，數(shù)據(jù)量不大，數(shù)據(jù)完全可以緩存?？梢钥紤]和余票庫放在一次。

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

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

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

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

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

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

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

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

3 車票庫分庫策略

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

 1. 功能需求

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

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

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

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

2. 負載均衡

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

3  高可用性

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

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

避免大多數(shù)據(jù)都在同一個庫，否則遇到大數(shù)據(jù)查詢數(shù)據(jù)庫負載會很高，進而影響系統(tǒng)整體的可用性。因為大多數(shù)請求都會排隊，導致系統(tǒng)資源耗盡。

　　5 可擴展性

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

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

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

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

通過以上的分庫策略，如果某一個庫宕機了，會影響1/10的購票用戶。

4 余票庫分庫策略

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

5 支付庫分庫策略

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

6 短信庫分庫策略

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

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

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

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

【編輯推薦】

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