一、基本概念
概念一：單庫
概念二：分片
分片解決“數據量太大”這一問題 ，也就是通常說的“水平切分”。
一旦引入分片，勢必面臨“數據路由”的新問題，數據到底要訪問哪個庫。 路由規則通常有 3 種方法：
（1）范圍： range
優點： 簡單，容易擴展。
缺點： 各庫壓力不均（新號段更活躍）。
（2）哈希： hash
優點： 簡單，數據均衡，負載均勻。
缺點： 遷移麻煩（2庫擴3庫數據要遷移）。
（3）統一路由服務： router-config-server
優點： 靈活性強，業務與路由算法解耦。
缺點： 每次訪問數據庫前多一次查詢。
大部分互聯網公司采用的方案二：哈希路由 。
概念三：分組
分組解決“可用性，性能提升”這一問題 ，分組通常通過主從復制的方式實現。
互聯網公司數據庫實際軟件架構是“ 既分片，又分組”：
數據庫軟件架構，究竟設計些什么呢， 至少要考慮以下四點：
- 如何保證數據 可用性
- 如何提高數據庫 讀性能 （大部分應用讀多寫少，讀會先成為瓶頸）
- 如何保證 一致性
- 如何提高 擴展性
二、如何保證數據的可用性？
解決可用性問題的思路是： 冗余 。
如何保證站點的可用性？ 冗余站點。
如何保證服務的可用性？ 冗余服務。
如何保證數據的可用性？ 冗余數據。
數據的冗余，會帶來一個副作用：一致性問題。
如何保證數據庫“讀”高可用？
冗余讀庫。
冗余讀庫帶來什么副作用？
讀寫有延時， 數據可能不一致 。
上圖是很多互聯網公司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還挺貴的。
三、如何擴展讀性能？
提高讀性能的方式大致有三種，第一種是 增加索引 。
這種方式不展開，要提到的一點是，不同的庫可以建立不同的索引。
如上圖：
（1）寫庫不建立索引；
（2）線上讀庫建立線上訪問索引，例如uid；
（3）線下讀庫建立線下訪問索引，例如time；
第二種擴充讀性能的方式是， 增加從庫 。
這種方法大家用的比較多，存在兩個缺點：
（1）從庫越多，同步越慢；
（2）同步越慢，數據不一致窗口越大；
第三種增加系統讀性能的方式是， 增加緩存 。
常見的緩存架構如下：
（1）上游是業務應用；
（2）下游是主庫，從庫（讀寫分離），緩存；
如果系統架構實施了 服務化 ：
（1）上游是業務應用；
（2）中間是服務；
（3）下游是 主庫，從庫，緩存 ；
業務層不直接面向db和cache，服務層屏蔽了底層db、cache的復雜性。
不管采用主從的方式擴展讀性能，還是緩存的方式擴展讀性能，數據都要復制多份（主+從，db+cache），一定會引發一致性問題。
四、如何保證一致性？
主從數據庫的一致性，通常有兩種解決方案：
（1）中間件
如果某一個key有寫操作，在不一致時間窗口內，中間件會將這個key的讀操作也路由到主庫上。
（2）強制讀主
“雙主高可用”的架構，主從一致性的問題能夠大大緩解。
第二類不一致，是db與緩存間的不一致。
這一類不一致，《緩存架構，一篇足夠？》里有非常詳細的敘述，本文不再展開。
另外建議，所有允許cache miss的業務場景，緩存中的KEY都設置一個超時時間，這樣即使出現不一致，有機會得到自修復。
