本文以MySQL數據庫為例說明。
一、數據庫架構原則有以下幾種：
1、高可用
2、高性能
3、一致性
4、擴展性
二、常見的架構方案：
- 方案一：主備架構，只有主庫提供讀寫服務，備庫冗余作故障轉移用
- 方案二：雙主架構，兩個主庫同時提供服務，負載均衡
- 方案三：主從架構，一主多從，讀寫分離
- 方案四：雙主+主從架構，看似完美的方案
三、弊端解決方案
任何方案都有弊端，有了弊端就要有應對方案。
- 第一類：主庫和從庫一致性解決方案
下面是解決數據不一致性產生的原因：
1、直接忽略，如果業務允許延時存在，那么就不去管它。
2、強制讀主，采用主備架構方案，讀寫都走主庫。用緩存來擴展數據庫讀性能 。有一點需要知道：如果緩存掛了，可能會產生雪崩現象，不過一般分布式緩存都是高可用的。
3、選擇讀主，寫操作時根據庫+表+業務特征生成一個key放到Cache里并設置超時時間（大于等于主從數據同步時間）。讀請求時，同樣的方式生成key先去查Cache，再判斷是否命中。若命中，則讀主庫，否則讀從庫。代價是多了一次緩存讀寫，基本可以忽略。
4、半同步復制，等主從同步完成，寫請求才返回。就是大家常說的“半同步復制”semi-sync。這可以利用數據庫原生功能，實現比較簡單。代價是寫請求時延增長，吞吐量降低。
5、數據庫中間件，引入開源（mycat等）或自研的數據庫中間層。個人理解，思路同選擇讀主。數據庫中間件的成本比較高，并且還多引入了一層。
- 第二類：DB和緩存一致性解決方案
下面是常用的緩存使用方式：
第一步：淘汰緩存；
第二步：寫入數據庫；
第三步：讀取緩存？返回：讀取數據庫；
第四步：讀取數據庫后寫入緩存。
四、總結
1、架構演變歷史
- 架構演變一：方案一 -> 方案一+分庫分表 -> 方案二+分庫分表 -> 方案四+分庫分表；
- 架構演變二：方案一 -> 方案一+分庫分表 -> 方案三+分庫分表 -> 方案四+分庫分表；
- 架構演變三：方案一 -> 方案二 -> 方案四 -> 方案四+分庫分表；
- 架構演變四：方案一 -> 方案三 -> 方案四 -> 方案四+分庫分表；
2、個人見解
- 加緩存和索引是通用的提升數據庫性能的方式；
- 分庫分表帶來的好處是巨大的，但同樣也會帶來一些問題。
- 不管是主備+分庫分表還是主從+讀寫分離+分庫分表，都要考慮具體的業務場景。
有報考軟件設計師而且想快速通過的朋友請私信我，給你傳授經驗。
