應對業務量的不斷增加場景通常有兩個大方向，一種是縱向擴充套件，也就是增加單台伺服器的cpu計算能力、記憶體容量和磁碟承載能力等；另外一種是橫向擴充套件，也就是通過增加伺服器的數量來增加處理能力。前者存在業務中斷和擴充套件上限等諸多的問題，特別是網際網路業務的迅猛發展，單台伺服器幾乎無法滿足業務負載要求，因此目前比較流行的方式橫向擴充套件的方式。
資料庫集群
資料庫的橫向擴充套件是通過資料庫集群實現的。資料庫集群也有兩種主要形式，一種是主備(主從)架構，也就是只有一台伺服器上的資料庫可以訪問，另乙個(多個)伺服器上資料庫不能訪問或者只能進行讀操作。另外一種是多活架構，這種架構中所有伺服器都可以對外提供服務(可同時讀寫)。
當前市面上大部分資料庫是主從架構，比如mysql和sql server等。如圖1是大名鼎鼎的mysql資料庫的主從複製原理圖。主從複製是通過重放binlog實現主庫資料的非同步複製。由於從binlog獲取資料並重放與主庫寫入資料存在時間延遲，因此從庫的資料總是要滯後主庫。這個也是主從架構的缺點，也就是無法保證資料的分布式一致性。主庫宕機的情況下可能會丟失一部分資料。
分割槽多活集群
多活架構是集群中的節點可以同時對外提供服務。根據集群中節點是否可以共享資料，多活架構又分為兩種。一種是非共享資料的多活，該種情況下集群節點不能共享資料，每個節點負責不同的資料。比如將資料庫表以主鍵id進行劃分(比如取模)，不同節點負責不同的區域。目前這種多活方案可以通過資料庫中介軟體實現，比如開源的mycat等。
如圖2所示是基於mycat的多活資料庫集群，這裡面主要劃分為2個區域，每個區域通過主備保證可用性和分攤負載。具體策略可以採用取模的方式，比如主鍵id為1,3,5,7…時資料儲存在左邊主庫中;2,4,6,8…時資料儲存在右邊主庫中。
由於資料的隔離性，上述訪問存在乙個主要問題就是擴容相對困難。當需要增加集群節點數量的時候，就需要重新劃分資料的儲存位置，從而需要做大量的資料遷移。這樣，不僅僅操作複雜，而且增加了出現問題的風險。
為了更加深入的理解oracle rac我們看一下其內部軟體模組的組成。整個資料庫層面沒有太多差異，這裡面主要多出了如下內容：虛擬ip(vip)、asm、clusterware和仲裁磁碟。這些新元件配合起來完成了oracle的多活集群功能。(堅果雲www.jianguoyun.com)
虛擬ip是應用訪問資料庫的入口，該ip並不與任何伺服器繫結，而是可以在集群的任意伺服器間漂移。由於具有這個特性，當出現伺服器宕機等情況時，資料集集群可以保證通過相同的介面對外提供服務。
asm與clusterware實現了集群管理功能，其中asm實現對磁碟的管理，避免同時訪問磁碟導致資料不一致的風險，而clusterware則用於管理oracle集群的軟體程序及資源排程。
仲裁磁碟用於集群中伺服器的異常判斷，集群中的節點通過定時更新仲裁磁碟中特定區域的資料標示自身的健康狀態。其它節點可以根據該資料判斷該節點是否宕機。
MySQL資料庫的集群解決方案（一）
讀寫分庫架構 我們一般應用對資料庫而言都是 讀多寫少 也就說對資料庫讀取資料的壓力比較大，有乙個思路就是說採用資料庫集群的方案 其中乙個是主庫，負責寫入資料，我們稱之為 寫庫 其它都是從庫，負責讀取資料，我們稱之為 讀庫 那麼，對我們的要求是 1.讀庫和寫庫的資料一致 2.寫資料必須寫到寫庫 3.讀...
MySQL資料庫的集群解決方案（二）
負載均衡 為了解決以上問題，我們將繼續優化架構，在應用程式和中介軟體之間增加proxy 由 來完成負載均衡的功能，應用程式只需要對接到proxy即可。proxy分發可以是隨機也可以是輪循 中介軟體比 做的事情要多，只做 壓力小。pxc集群架構 在前面的架構中，都是基於mysql主從的架構，那麼在主從...
資料庫集群和高可用解決方案
概述 盡可能的讓資料庫處於可用狀態。提供高可用解決方案要考慮的因素 1 rto recovery time objective 允許的離線時間，2 rpo recovery point objective 允許的資料丟失量 rto和pro統稱為 sla service level agrement ...