一文帶你看透數(shù)據(jù)庫架構(gòu)的演變過程

背景

在互聯(lián)網(wǎng)初創(chuàng)時(shí)期，企業(yè)往往采用單體架構(gòu)去搭建自己的應(yīng)用系統(tǒng)，但是，隨著企業(yè)的不斷壯大，系統(tǒng)訪問量不斷隨之上升，數(shù)據(jù)量也急劇增長(zhǎng)。數(shù)據(jù)的存儲(chǔ)是首先要解決的問題，在這個(gè)大數(shù)據(jù)時(shí)代，數(shù)據(jù)就是企業(yè)的命根子，數(shù)據(jù)庫的單體架構(gòu)很難滿足數(shù)據(jù)的存儲(chǔ)，這時(shí)，我們要對(duì)數(shù)據(jù)進(jìn)行切分，數(shù)據(jù)的切分又分為垂直切分和水平切分。

數(shù)據(jù)切分和數(shù)據(jù)庫架構(gòu)

在數(shù)據(jù)切分之前，我們的所有業(yè)務(wù)都放在一個(gè)數(shù)據(jù)庫中，比如：我們的用戶業(yè)務(wù)，商品業(yè)務(wù)，訂單業(yè)務(wù)。數(shù)據(jù)庫的架構(gòu)如下：

在業(yè)務(wù)發(fā)展到一定規(guī)模時(shí)，一個(gè)數(shù)據(jù)庫很難滿足數(shù)據(jù)的存儲(chǔ)，并且導(dǎo)致數(shù)據(jù)的訪問比較慢，導(dǎo)致用戶的流失。這時(shí)，我們要對(duì)數(shù)據(jù)進(jìn)行切分，使其從單一的數(shù)據(jù)庫的存儲(chǔ)分散到多個(gè)數(shù)據(jù)庫的存儲(chǔ)。在進(jìn)行數(shù)據(jù)切分時(shí)，我們要遵循先垂直后水平的原則。

數(shù)據(jù)的垂直切分也就是數(shù)據(jù)的縱向切分，按照業(yè)務(wù)將數(shù)據(jù)進(jìn)行切分。在上面的例子中，我們將一個(gè)數(shù)據(jù)庫切分為：用戶庫，商品庫，訂單庫。將原來的一個(gè)數(shù)據(jù)庫分為了三個(gè)數(shù)據(jù)庫，分散了數(shù)據(jù)的存儲(chǔ)壓力，同時(shí)也分散了數(shù)據(jù)的讀取壓力。如圖所示：

但是，隨著業(yè)務(wù)的發(fā)展，單個(gè)業(yè)務(wù)庫也會(huì)遇到存儲(chǔ)的瓶頸，比如：用戶的急劇增長(zhǎng)，導(dǎo)致單一的用戶庫無法存儲(chǔ)，用戶訪問的速度變慢等。這時(shí)，我們就要對(duì)數(shù)據(jù)進(jìn)行水平切分了，將用戶按照某種規(guī)則平均分配到多個(gè)數(shù)據(jù)庫中，也就是將原來的單一的用戶庫進(jìn)行了水平擴(kuò)展。如圖所示：

這里，我們只是水平的拆分了兩個(gè)庫，大家可以根據(jù)自己的系統(tǒng)情況，拆分成更多的數(shù)據(jù)庫。

分庫分表中間件MyCAT

數(shù)據(jù)庫的整體架構(gòu)我們規(guī)劃好了，那么我們?cè)谶M(jìn)行開發(fā)的時(shí)候，怎么確定一條數(shù)據(jù)從哪個(gè)數(shù)據(jù)庫讀取呢？或者插入一條數(shù)據(jù)的時(shí)候，這條數(shù)據(jù)要插入到哪一個(gè)數(shù)據(jù)庫呢？數(shù)據(jù)庫的選擇是交給開發(fā)人員負(fù)責(zé)呢？還是統(tǒng)一的設(shè)置一個(gè)代理層呢？開發(fā)人員在開發(fā)的時(shí)候，關(guān)注的焦點(diǎn)是業(yè)務(wù)，復(fù)雜的業(yè)務(wù)已經(jīng)占據(jù)了他們大部分的精力，如果再讓他們?nèi)タ紤]數(shù)據(jù)庫的問題，對(duì)他們的壓力是非常大的，而且每個(gè)開發(fā)人員的代碼風(fēng)格也不一樣，導(dǎo)致項(xiàng)目混亂，臃腫，難以維護(hù)。所以，我們往往采用代理層統(tǒng)一處理數(shù)據(jù)的分片，這時(shí)，我們的MyCAT分庫分表中間件就登場(chǎng)了，它去做統(tǒng)一的數(shù)據(jù)庫層的代理。如圖：

MyCAT統(tǒng)一做數(shù)據(jù)庫層的代理，對(duì)外暴露一個(gè)地址，應(yīng)用系統(tǒng)直接連接MyCAT，就像連接普通的MySQL一樣，沒有任何的區(qū)別。所有的CRUD操作都直接對(duì)應(yīng)MyCAT，再由MyCAT做具體的數(shù)據(jù)分片，數(shù)據(jù)分片的過程對(duì)于開發(fā)人員來說是透明的，不需要額外的處理，這樣，開發(fā)人員只需要關(guān)注業(yè)務(wù)就可以了。

MyCAT集群

可用性對(duì)于一個(gè)系統(tǒng)來說是非常重要的，尤其是在當(dāng)今的互聯(lián)網(wǎng)時(shí)代，系統(tǒng)宕機(jī)1分鐘，帶來的損失都是非常嚴(yán)重的，所以，我們?cè)诖罱ㄏ到y(tǒng)時(shí)，往往采用集群方式，某一個(gè)節(jié)點(diǎn)的不可用，不影響整體系統(tǒng)的可用性。在前面的例子中，我們所有的節(jié)點(diǎn)都是單節(jié)點(diǎn)，存在著單點(diǎn)故障，這是我們不希望看到的，所以我們要搭建集群。6個(gè)業(yè)務(wù)數(shù)據(jù)庫我們都可以做主從，這時(shí)，用戶1庫可以搭建為 用戶1（主）和用戶1（從），用戶2庫可以搭建為 用戶2（主）和用戶2（從）。訂單庫和商品庫也可以做同樣的操作，如圖：

這樣我們的業(yè)務(wù)數(shù)據(jù)庫不存在單點(diǎn)故障了，但是MyCAT成為了單點(diǎn)，如果MyCAT發(fā)生故障，或者M(jìn)yCAT承載了大量的數(shù)據(jù)庫的請(qǐng)求，MyCAT成了整個(gè)系統(tǒng)的唯一瓶頸。那么MyCAT我們?nèi)绾未罱耗?？有的小伙伴可能?huì)說了，我們?cè)俨渴鹨粋€(gè)MyCAT，這個(gè)MyCAT和前一個(gè)MyCAT配置一樣就可以了。是的，這只是其中的第一步，我們有了兩個(gè)MyCAT連接數(shù)據(jù)庫，那么我們的應(yīng)用系統(tǒng)也需要連接兩個(gè)MyCAT嗎？?jī)蓚€(gè)MyCAT我們要如何分配請(qǐng)求呢？這是不是又增加了應(yīng)用系統(tǒng)的復(fù)雜性呢？所以，我們?cè)趦蓚€(gè)MyCAT上面再增加一個(gè)負(fù)載均衡器，它可以將請(qǐng)求按照某種規(guī)則分配到兩個(gè)MyCAT上，這個(gè)負(fù)載均衡器我們采用HAProxy。整體架構(gòu)如圖：

這樣MyCAT的單點(diǎn)故障解決了，但是HAProxy又成了單點(diǎn)，這是不是很有意思，似乎總有一個(gè)單點(diǎn)解決不了。在這里最后一個(gè)單點(diǎn)HAProxy，我們使用KeepAlived做故障轉(zhuǎn)移就可以解決了，兩個(gè)KeepAlived可以提供一個(gè)虛擬IP，業(yè)務(wù)系統(tǒng)直接連接這個(gè)虛擬IP，后面的過程對(duì)于應(yīng)用系統(tǒng)是透明的。如圖所示：

這就是我們最終的數(shù)據(jù)庫架構(gòu)，不存在任何的單點(diǎn)故障。

分布式事務(wù)與分布式ID

進(jìn)行了分庫分表后，隨之而來的問題也就出現(xiàn)了，那就是ID的問題和分布式事務(wù)的問題，分布式ID和分布式事務(wù)在MyCAT中都有相應(yīng)的解決方案，我們?cè)贛yCAT中進(jìn)行配置就可以了。