一、基本概念
概念一：單庫
概念二：分片
分片解決“資料量太大”這一問題，也就是通常說的“水準切分”。
一旦引入分片，勢必面臨“資料路由”的新問題，資料到底要通路哪個庫。路由規則通常有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）下遊是主庫，從庫（讀寫分離），緩存；
如果系統架構實施了服務化：
（2）中間是服務；
（3）下遊是主庫，從庫，緩存；
業務層不直接面向db和cache，服務層屏蔽了底層db、cache的複雜性。
不管采用主從的方式擴充讀性能，還是緩存的方式擴充讀性能，資料都要複制多份（主+從，db+cache），一定會引發一緻性問題。
四、如何保證一緻性？
主從資料庫的一緻性，通常有兩種解決方案：
（1）中間件
如果某一個key有寫操作，在不一緻時間視窗内，中間件會将這個key的讀操作也路由到主庫上。
（2）強制讀主
“雙主高可用”的架構，主從一緻性的問題能夠大大緩解。
第二類不一緻，是db與緩存間的不一緻。
這一類不一緻，《緩存架構，一篇足夠？》裡有非常詳細的叙述，本文不再展開。
另外建議，所有允許cache miss的業務場景，緩存中的KEY都設定一個逾時時間，這樣即使出現不一緻，有機會得到自修複。
資料庫軟體架構，到底要設計些什麼？
- 可用性
- 讀性能
- 一緻性
- 擴充性
希望對大家系統性了解資料庫軟體架構有幫助。
架構師之路-分享可落地技術