一文帶你看透數據庫架構的演變過程

背景

在互聯網初創時期，企業往往采用單體架構去搭建自己的應用系統，但是，隨著企業的不斷壯大，系統訪問量不斷隨之上升，數據量也急劇增長。數據的存儲是首先要解決的問題，在這個大數據時代，數據就是企業的命根子，數據庫的單體架構很難滿足數據的存儲，這時，我們要對數據進行切分，數據的切分又分為垂直切分和水平切分。

數據切分和數據庫架構

在數據切分之前，我們的所有業務都放在一個數據庫中，比如：我們的用戶業務，商品業務，訂單業務。數據庫的架構如下：

在業務發展到一定規模時，一個數據庫很難滿足數據的存儲，并且導致數據的訪問比較慢，導致用戶的流失。這時，我們要對數據進行切分，使其從單一的數據庫的存儲分散到多個數據庫的存儲。在進行數據切分時，我們要遵循先垂直后水平的原則。

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

但是，隨著業務的發展，單個業務庫也會遇到存儲的瓶頸，比如：用戶的急劇增長，導致單一的用戶庫無法存儲，用戶訪問的速度變慢等。這時，我們就要對數據進行水平切分了，將用戶按照某種規則平均分配到多個數據庫中，也就是將原來的單一的用戶庫進行了水平擴展。如圖所示：

這里，我們只是水平的拆分了兩個庫，大家可以根據自己的系統情況，拆分成更多的數據庫。

分庫分表中間件MyCAT

數據庫的整體架構我們規劃好了，那么我們在進行開發的時候，怎么確定一條數據從哪個數據庫讀取呢？或者插入一條數據的時候，這條數據要插入到哪一個數據庫呢？數據庫的選擇是交給開發人員負責呢？還是統一的設置一個代理層呢？開發人員在開發的時候，關注的焦點是業務，復雜的業務已經占據了他們大部分的精力，如果再讓他們去考慮數據庫的問題，對他們的壓力是非常大的，而且每個開發人員的代碼風格也不一樣，導致項目混亂，臃腫，難以維護。所以，我們往往采用代理層統一處理數據的分片，這時，我們的MyCAT分庫分表中間件就登場了，它去做統一的數據庫層的代理。如圖：

MyCAT統一做數據庫層的代理，對外暴露一個地址，應用系統直接連接MyCAT，就像連接普通的MySQL一樣，沒有任何的區別。所有的CRUD操作都直接對應MyCAT，再由MyCAT做具體的數據分片，數據分片的過程對于開發人員來說是透明的，不需要額外的處理，這樣，開發人員只需要關注業務就可以了。

MyCAT集群

可用性對于一個系統來說是非常重要的，尤其是在當今的互聯網時代，系統宕機1分鐘，帶來的損失都是非常嚴重的，所以，我們在搭建系統時，往往采用集群方式，某一個節點的不可用，不影響整體系統的可用性。在前面的例子中，我們所有的節點都是單節點，存在著單點故障，這是我們不希望看到的，所以我們要搭建集群。6個業務數據庫我們都可以做主從，這時，用戶1庫可以搭建為 用戶1（主）和用戶1（從），用戶2庫可以搭建為 用戶2（主）和用戶2（從）。訂單庫和商品庫也可以做同樣的操作，如圖：

這樣我們的業務數據庫不存在單點故障了，但是MyCAT成為了單點，如果MyCAT發生故障，或者MyCAT承載了大量的數據庫的請求，MyCAT成了整個系統的唯一瓶頸。那么MyCAT我們如何搭建集群呢？有的小伙伴可能會說了，我們再部署一個MyCAT，這個MyCAT和前一個MyCAT配置一樣就可以了。是的，這只是其中的第一步，我們有了兩個MyCAT連接數據庫，那么我們的應用系統也需要連接兩個MyCAT嗎？兩個MyCAT我們要如何分配請求呢？這是不是又增加了應用系統的復雜性呢？所以，我們在兩個MyCAT上面再增加一個負載均衡器，它可以將請求按照某種規則分配到兩個MyCAT上，這個負載均衡器我們采用HAProxy。整體架構如圖：

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

這就是我們最終的數據庫架構，不存在任何的單點故障。

分布式事務與分布式ID

進行了分庫分表后，隨之而來的問題也就出現了，那就是ID的問題和分布式事務的問題，分布式ID和分布式事務在MyCAT中都有相應的解決方案，我們在MyCAT中進行配置就可以了。