數據庫讀寫分離架構，爲何我不喜歡

RD：單庫數據量太大，數據庫扛不住了，我要申請一個數據庫從庫，讀寫分離。
DBA：數據量多少？
RD：5000w左右。
DBA：讀寫吞吐量呢？
RD：讀QPS約200，寫QPS約30左右。

上週在公司聽到兩個技術同窗討論，感受對讀寫分離解決什麼問題沒有弄清楚，有些奔潰。

另，對於互聯網某些業務場景，並非很喜歡數據庫讀寫分離架構，一些淺見見文末。

1、讀寫分離

什麼是數據庫讀寫分離？

答：一主多從，讀寫分離，主動同步，是一種常見的數據庫架構，通常來講：

• 主庫，提供數據庫寫服務
• 從庫，提供數據庫讀服務
• 主從之間，經過某種機制同步數據，例如mysql的binlog
  一個組從同步集羣一般稱爲一個「分組」。

分組架構究竟解決什麼問題？

答：大部分互聯網業務讀多寫少，數據庫的讀每每最早成爲性能瓶頸，若是但願：

• 線性提高數據庫讀性能
• 經過消除讀寫鎖衝突提高數據庫寫性能
  此時可使用分組架構。

一句話，分組主要解決「數據庫讀性能瓶頸」問題，在數據庫扛不住讀的時候，一般讀寫分離，經過增長從庫線性提高系統讀性能。

2、水平切分

什麼是數據庫水平切分？

答：水平切分，也是一種常見的數據庫架構，通常來講：

• 每一個數據庫之間沒有數據重合，沒有相似binlog同步的關聯
• 全部數據並集，組成所有數據
• 會用算法，來完成數據分割，例如「取模」
  一個水平切分集羣中的每個數據庫，一般稱爲一個「分片」。

水平切分架構究竟解決什麼問題？

答：大部分互聯網業務數據量很大，單庫容量容易成爲瓶頸，若是但願：

• 線性下降單庫數據容量
• 線性提高數據庫寫性能
  此時可使用水平切分架構。

一句話總結，水平切分主要解決「數據庫數據量大」問題，在數據庫容量扛不住的時候，一般水平切分。

3、爲何不喜歡讀寫分離

對於互聯網大數據量，高併發量，高可用要求高，一致性要求高，前端面向用戶的業務場景，若是數據庫讀寫分離：

• 數據庫鏈接池須要區分：讀鏈接池，寫鏈接池
• 若是要保證讀高可用，讀鏈接池要實現故障自動轉移

• 有潛在的主庫從庫一致性問題

• 若是面臨的是「讀性能瓶頸」問題，增長緩存可能來得更直接，更容易一點
• 關於成本，從庫的成本比緩存高很多
• 對於雲上的架構，以阿里云爲例，主庫提供高可用服務，從庫不提供高可用服務

因此，上述業務場景下，樓主建議使用緩存架構來增強系統讀性能，替代數據庫主從分離架構。

固然，使用緩存架構的潛在問題：若是緩存掛了，流量所有壓到數據庫上，數據庫會雪崩。不過幸虧，雲上的緩存通常都提供高可用的服務。

4、總結

• 讀寫分離，解決「數據庫讀性能瓶頸」問題
• 水平切分，解決「數據庫數據量大」問題
• 對於互聯網大數據量，高併發量，高可用要求高，一致性要求高，前端面向用戶的業務場景，微服務緩存架構，可能比數據庫讀寫分離架構更合適

你有沒有用讀寫分離，你的思考是什麼呢？

但願這一分鐘你有收穫。隨手轉，謝過。