建站
咨詢
售后
建站咨詢
新聞中心
最近看了很多公司架構(gòu)的演變的文章，發(fā)現(xiàn)其中的基本思路和架構(gòu)演變都很類似，這里也總結(jié)一下數(shù)據(jù)庫架構(gòu)的演變以及演變背后的思路。
最開始網(wǎng)站一般都是由典型的LAMP架構(gòu)演變而來的，一般都是一臺linux主機(jī)，一臺apache服務(wù)器，php執(zhí)行環(huán)境以及mysql服務(wù)器，一般情況下，這些都在一臺虛擬主機(jī)上，簡稱單主機(jī)模式。
單主機(jī)模式缺點(diǎn)：
1 web服務(wù)器和mysql服務(wù)器公用一臺主機(jī)，共享硬件資源，可能存在某一方資源征用太大，導(dǎo)致整個應(yīng)用產(chǎn)生瓶頸
2 當(dāng)業(yè)務(wù)增長之后，沒有辦法做到橫向擴(kuò)展。
3 容錯性太差，一旦主機(jī)存在問題，整個應(yīng)用不可用
獨(dú)立主機(jī)隨著業(yè)務(wù)的發(fā)展，可以把mysql服務(wù)器和web服務(wù)器主機(jī)分開，分別部署，就是獨(dú)立主機(jī)模式。
獨(dú)立主機(jī)模式下，web服務(wù)器和mysql不再共享硬件資源，分別部署。沒有把雞蛋放在一個籃子里面，增加了容錯性。如果只是mysql服務(wù)器故障，那么對于web上不訪問服務(wù)器的應(yīng)用是不會受到影響的。而且web服務(wù)器可以做到橫向擴(kuò)展，如果web服務(wù)器性能不夠，可以增加多臺web服務(wù)器，進(jìn)行負(fù)載均衡，分散web服務(wù)器的壓力。
獨(dú)立主機(jī)模式的缺點(diǎn)：
1 可擴(kuò)展性問題：雖然web服務(wù)器可以做到橫向擴(kuò)展，但是mysql服務(wù)器是沒有辦法做到橫向擴(kuò)展的。
2 可用性問題：mysql服務(wù)器存在單點(diǎn)問題，一旦mysql服務(wù)器宕機(jī)，對影響的影響很大
3 性能問題：單臺mysql服務(wù)器能夠支撐的服務(wù)是有限的。
讀寫分離隨著業(yè)務(wù)的不斷發(fā)展，數(shù)據(jù)庫的壓力會越來越大，單數(shù)據(jù)庫慢慢的就不能滿足需求了，一些網(wǎng)站對數(shù)據(jù)實(shí)時性要求不高，就會慢慢發(fā)展讀寫分離模式，對于普通的查詢請求，分配到讀庫（也可以說是備庫），對于修改請求，在主庫上完成。對于讀庫，由于是無狀態(tài)的，可以做到橫向擴(kuò)展。對于寫庫，還只能是單臺主機(jī)
這種模式其實(shí)有限制的，要根據(jù)業(yè)務(wù)的類型來考慮。主庫的數(shù)據(jù)是最新的，但是同步到讀庫會有時延，所以應(yīng)用必須能夠容忍短暫的不一致性。對于一致性要求非常高的場景是不適合的。
這種模式的存在的問題：
1 可擴(kuò)展性：雖然讀庫可以做到橫向擴(kuò)展，但是寫庫還不行，讀庫不能夠橫向擴(kuò)展
2 可用性：讀庫成為單點(diǎn)，一旦故障，影響所有的寫操作業(yè)務(wù)
業(yè)務(wù)垂直拆分隨著業(yè)務(wù)的發(fā)展，一臺寫庫顯然不能夠滿足高并發(fā)的情況，但是考慮到寫庫是有狀態(tài)的，不能簡單的橫向擴(kuò)展，假設(shè)有兩臺寫庫，那么隨機(jī)更新一臺的數(shù)據(jù)，就會導(dǎo)致另一方數(shù)據(jù)存在問題。出現(xiàn)一種數(shù)據(jù)兩個不同版本，顯然是無法接受的。在寫庫上，可以考慮按照業(yè)務(wù)來垂直進(jìn)行分庫。由于我們這里討論的是數(shù)據(jù)庫架構(gòu)，對于web層來說，其實(shí)也是可以按照業(yè)務(wù)垂直拆分的。
在按照業(yè)務(wù)垂直拆分以后，系統(tǒng)在性能上有了很高的提升，只需要把業(yè)務(wù)上分成垂直部分，分的越細(xì)，系統(tǒng)的整體擴(kuò)展能力就越強(qiáng)。
這種模式下，存在以下幾個問題
1 可用性：假設(shè)一個完整的業(yè)務(wù)流程P訪問的數(shù)據(jù)庫被拆分為A、B、C、D、E 五個庫，假設(shè)每個寫庫可用性為99%，那么這個業(yè)務(wù)流程P的可用性就為99%*99%*99%*99%*99%=95%,庫拆分的越多，對系統(tǒng)的整體可用性挑戰(zhàn)就越大。
2 性能：由于垂直業(yè)務(wù)庫每個庫的負(fù)載可能不一樣，假設(shè)交易庫負(fù)載很高，一個交易寫庫肯定不能夠滿足需求，這個情況下，交易庫成為整個系統(tǒng)的瓶頸。
3 可擴(kuò)展性：單個節(jié)點(diǎn)的可擴(kuò)展性沒有得到改善，交易庫不能單獨(dú)進(jìn)行擴(kuò)展。
單業(yè)務(wù)庫水平、垂直拆分在上一種情況，假設(shè)交易庫是整個系統(tǒng)的瓶頸，需要對交易庫進(jìn)行單獨(dú)的擴(kuò)展?？梢钥紤]交易的水平拆分或者垂直拆分，有可能同時進(jìn)行兩種方式拆分。
水平拆分一般根據(jù)業(yè)務(wù)無關(guān)的關(guān)鍵字進(jìn)行拆分，橫向擴(kuò)展性比較好，但是對于查詢的挑戰(zhàn)比較大
垂直拆分一般根據(jù)業(yè)務(wù)來拆分，但是可能導(dǎo)致數(shù)據(jù)不均勻以及拆分不夠靈活。對于查詢來說，相對比較友好
拿交易庫舉個例子，可以先交易的類型進(jìn)行業(yè)務(wù)上的垂直分庫，在按照訂單號進(jìn)行水平分庫。
假設(shè)可以分成M*N個庫，那么單個庫的故障會影響1/M*N 的交易，但是假設(shè)每個庫可用性為99% ，那么交易數(shù)據(jù)庫故障概率為 (99%)的(M+N)次方，如果數(shù)據(jù)庫拆分的越多，發(fā)生單個數(shù)據(jù)庫故障概率就越高。
這種方式存在的問題：
1 雖然單個節(jié)點(diǎn)故障影響的用戶很少，但是整體可用會降低。
2 數(shù)據(jù)庫管理上帶來復(fù)雜的挑戰(zhàn)，假設(shè)交易庫表結(jié)構(gòu)變更，需要執(zhí)行M×N次腳本變更。
3 由于發(fā)生單個數(shù)據(jù)庫故障的概率比較高，dba會很苦逼的，估計經(jīng)常性要救火
4 開發(fā)和測試起來會非?？啾?，開發(fā)和測試成本會變高，查詢非常復(fù)雜。
5 單個節(jié)點(diǎn)如果發(fā)生故障，沒有失敗檢測并且切換機(jī)制
6 分庫還不能在水平方向做到無限擴(kuò)展，我們的算法是事先分配M個庫，如果添加一個庫基本上不可行
隨機(jī)分庫對于第六個問題，在水平方向的無線擴(kuò)展，可以考慮一種機(jī)制，在insert數(shù)據(jù)的時候，申請一個數(shù)據(jù)庫編號，然后把數(shù)據(jù)庫的編號作為一個字段保存或者在把這個編號添加到已經(jīng)字段上。
例如假設(shè)我們申請insert數(shù)據(jù)庫，得到一個數(shù)據(jù)庫編號為1000，那么我們可以構(gòu)造出來一個訂單號為1000_tradeno，訂單號前面是分庫編號，訂單號后面是實(shí)際tradeno，這樣解決了水平無線擴(kuò)展的問題。這種就是隨機(jī)分庫模式。但是這一種方式的局限性很大，
隨機(jī)分庫的缺點(diǎn)：
1 分庫算法和業(yè)務(wù)耦合在一起，比較適合特定的場景，適用范圍比較窄
2 對于insert操作，比較容易，對于update操作，必須有分庫編號，也就是說，只能根據(jù)特定的字段來進(jìn)行更新
3 不適合批量查詢的場景，查詢功能限制比較大，這也是分庫帶來的問題
單數(shù)據(jù)庫備份以及失敗切換對于單個數(shù)據(jù)庫，如果發(fā)生故障，會影響業(yè)務(wù)，但是能否在發(fā)生故障的時候進(jìn)行切換。雖然可以實(shí)現(xiàn)，但是會存在一定的問題，需要特定場景進(jìn)行特定的分析。這一塊比較復(fù)雜，說起來可以在寫一篇文章，就簡單的介紹一下
以上就是總結(jié)的數(shù)據(jù)庫的架構(gòu)演變，數(shù)據(jù)庫的演變需要很多基礎(chǔ)技術(shù)做支撐，主要包括
1 強(qiáng)大的分布式數(shù)據(jù)庫的管理中間件，主要屏蔽底層的數(shù)據(jù)庫路由以及數(shù)據(jù)管理功能
2 強(qiáng)大的數(shù)據(jù)運(yùn)維團(tuán)隊(duì)以及監(jiān)控體系，能夠檢測出每個節(jié)點(diǎn)的數(shù)據(jù)庫狀態(tài)
3 強(qiáng)大的數(shù)據(jù)庫管理管理團(tuán)隊(duì)，能夠維護(hù)這么的數(shù)據(jù)庫集群
4 強(qiáng)大的業(yè)務(wù)架構(gòu)能力和技術(shù)架構(gòu)能力，能夠掌控這么復(fù)雜的業(yè)務(wù)場景。
分享題目：數(shù)據(jù)庫架構(gòu)的演變
本文鏈接：http://fisionsoft.com.cn/article/cjdjdd.html
