一、基本概念

概念一：單庫

概念二：分片

分片解決“數據量太大”這一問題，也就是通常說的“水平切分”。

一旦引入分片，勢必面臨“數據路由”的新問題，數據到底要訪問哪個庫。路由規則通常有3種方法：

(1)范圍：range

• 優點：簡單，容易擴展。
• 缺點：各庫壓力不均(新號段更活躍)。

(2)哈希：hash

• 優點：簡單，數據均衡，負載均勻。
• 缺點：遷移麻煩(2庫擴3庫數據要遷移)。

(3)統一路由服務：router-config-server

• 優點：靈活性強，業務與路由算法解耦。
• 缺點：每次訪問數據庫前多一次查詢。

大部分互聯網公司采用的方案二：哈希路由。

概念三：分組

分組解決“可用性，性能提升”這一問題，分組通常通過主從復制的方式實現。

互聯網公司數據庫實際軟件架構是“既分片，又分組”：

數據庫軟件架構，究竟設計些什么呢，至少要考慮以下四點：

• 如何保證數據可用性
• 如何提高數據庫讀性能(大部分應用讀多寫少，讀會先成為瓶頸)
• 如何保證一致性
• 如何提高擴展性

二、如何保證數據的可用性?

解決可用性問題的思路是：冗余。

• 如何保證站點的可用性?冗余站點。
• 如何保證服務的可用性?冗余服務。
• 如何保證數據的可用性?冗余數據。

數據的冗余，會帶來一個副作用：一致性問題。

1. 如何保證數據庫“讀”高可用?

冗余讀庫。

2. 冗余讀庫帶來什么副作用?

讀寫有延時，數據可能不一致。

上圖是很多互聯網公司mysql的架構，寫仍然是單點，不能保證寫高可用。

3. 如何保證數據庫“寫”高可用?

冗余寫庫。

采用雙主互備的方式，可以冗余寫庫。

4. 冗余寫庫帶來什么副作用?

雙寫同步，數據可能沖突(例如“自增id”同步沖突)。

如何解決同步沖突，有兩種常見解決方案：

• 兩個寫庫使用不同的初始值，相同的步長來增加id：1寫庫的id為0,2,4,6...;2寫庫的id為1,3,5,7…;
• 不使用數據的id，業務層自己生成唯一的id，保證數據不沖突;

阿里云的RDS服務號稱寫高可用，是如何實現的呢?

他們采用的就是類似于“雙主同步”的方式(不再有從庫了)。

仍是雙主，但只有一個主提供讀寫服務，另一個主是“shadow-master”，只用來保證高可用，平時不提供服務。

master掛了，shadow-master頂上，虛IP漂移，對業務層透明，不需要人工介入。

這種方式的好處：

• 讀寫沒有延時，無一致性問題;
• 讀寫高可用;

不足是：

• 不能通過加從庫的方式擴展讀性能;
• 資源利用率為50%，一臺冗余主沒有提供服務;

畫外音：所以，高可用RDS還挺貴的。

三、如何擴展讀性能?

提高讀性能的方式大致有三種，第一種是增加索引。

這種方式不展開，要提到的一點是，不同的庫可以建立不同的索引。

如上圖：

• 寫庫不建立索引;
• 線上讀庫建立線上訪問索引，例如uid;
• 線下讀庫建立線下訪問索引，例如time;

第二種擴充讀性能的方式是，增加從庫。

這種方法大家用的比較多，存在兩個缺點：

• 從庫越多，同步越慢;
• 同步越慢，數據不一致窗口越大;

第三種增加系統讀性能的方式是，增加緩存。

常見的緩存架構如下：

• 上游是業務應用;
• 下游是主庫，從庫(讀寫分離)，緩存;

如果系統架構實施了服務化：

• 上游是業務應用;
• 中間是服務;
• 下游是主庫，從庫，緩存;

業務層不直接面向db和cache，服務層屏蔽了底層db、cache的復雜性。

不管采用主從的方式擴展讀性能，還是緩存的方式擴展讀性能，數據都要復制多份(主+從，db+cache)，一定會引發一致性問題。

四、如何保證一致性?

主從數據庫的一致性，通常有兩種解決方案：

1. 中間件

如果某一個key有寫操作，在不一致時間窗口內，中間件會將這個key的讀操作也路由到主庫上。

2. 強制讀主

“雙主高可用”的架構，主從一致性的問題能夠大大緩解。

第二類不一致，是db與緩存間的不一致。

另外建議，所有允許cache miss的業務場景，緩存中的KEY都設置一個超時時間，這樣即使出現不一致，有機會得到自修復。

五、如何保障數據庫的擴展性?

秒級成倍數據庫擴容：《億級數據DB秒級平滑擴容》

如果不是成倍擴容：《100億數據平滑數據遷移,不影響服務》

也可能，是要對字段進行擴展：《1萬屬性，100億數據，架構設計?》

這些方案，都有相關文章展開寫過，本文不再贅述。

數據庫軟件架構，到底要設計些什么?

• 可用性
• 讀性能
• 一致性
• 擴展性

希望對大家系統性理解數據庫軟件架構有幫助。

【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】

戳這里，看該作者更多好文