數據庫軟件架構，到底要設計些什麼？

1、基本概念

概念一：單庫

概念二：分片

分片解決「數據量太大」這一問題，也就是一般說的「水平切分」。
mysql

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

（1）範圍：range

優勢：簡單，容易擴展。
缺點：各庫壓力不均（新號段更活躍）。
sql

（2）哈希：hash

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

（3）統一路由服務：router-config-server

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

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

概念三：分組

分組解決「可用性，性能提高」這一問題，分組一般經過主從複製的方式實現。
ide

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

工具

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

如何保證數據可用性
如何提升數據庫讀性能（大部分應用讀多寫少，讀會先成爲瓶頸）
如何保證一致性
如何提升擴展性

2、如何保證數據的可用性？

解決可用性問題的思路是：冗餘。優化

如何保證站點的可用性？冗餘站點。
如何保證服務的可用性？冗餘服務。
如何保證數據的可用性？冗餘數據。

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

如何保證數據庫「讀」高可用？

冗餘讀庫。

冗餘讀庫帶來什麼反作用？
讀寫有延時，數據可能不一致。
上圖是不少互聯網公司mysql的架構，寫仍然是單點，不能保證寫高可用。

如何保證數據庫「寫」高可用？

冗餘寫庫。

採用雙主互備的方式，能夠冗餘寫庫。

冗餘寫庫帶來什麼反作用？
雙寫同步，數據可能衝突（例如「自增id」同步衝突）。

如何解決同步衝突，有兩種常看法決方案：
（1）兩個寫庫使用不一樣的初始值，相同的步長來增長id：1寫庫的id爲0,2,4,6...；2寫庫的id爲1,3,5,7…；
（2）不使用數據的id，業務層本身生成惟一的id，保證數據不衝突；

阿里雲的RDS服務號稱寫高可用，是如何實現的呢？
他們採用的就是相似於「雙主同步」的方式（再也不有從庫了）。

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

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

這種方式的好處：
（1）讀寫沒有延時，無一致性問題；
（2）讀寫高可用；

不足是：
（1）不能經過加從庫的方式擴展讀性能；
（2）資源利用率爲50%，一臺冗餘主沒有提供服務；
畫外音：因此，高可用RDS還挺貴的。

3、如何擴展讀性能？

提升讀性能的方式大體有三種，第一種是增長索引。

這種方式不展開，要提到的一點是，不一樣的庫能夠創建不一樣的索引。

如上圖：
（1）寫庫不創建索引；
（2）線上讀庫創建線上訪問索引，例如uid；
（3）線下讀庫創建線下訪問索引，例如time；

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

這種方法你們用的比較多，存在兩個缺點：
（1）從庫越多，同步越慢；
（2）同步越慢，數據不一致窗口越大；

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

常見的緩存架構以下：

（1）上游是業務應用；
（2）下游是主庫，從庫（讀寫分離），緩存；

若是系統架構實施了服務化：
（1）上游是業務應用；
（2）中間是服務；
（3）下游是主庫，從庫，緩存；

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

無論採用主從的方式擴展讀性能，仍是緩存的方式擴展讀性能，數據都要複製多份（主+從，db+cache），必定會引起一致性問題。

4、如何保證一致性？

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

（1）中間件

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

（2）強制讀主

「雙主高可用」的架構，主從一致性的問題可以大大緩解。

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

這一類不一致，《緩存架構，一篇足夠？》裏有很是詳細的敘述，本文再也不展開。

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

5、如何保障數據庫的擴展性？