RD：單庫數據量太大，數據庫扛不住了，我要申請一個數據庫從庫，讀寫分離。

DBA：數據量多少?

RD：5000w左右。

DBA：讀寫吞吐量呢?

RD：讀QPS約200，寫QPS約30左右。

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

另外，對于互聯網某些業務場景，并不是很喜歡數據庫讀寫分離架構，一些淺見見文末。

一、讀寫分離

1. 什么是數據庫讀寫分離?

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

• 主庫，提供數據庫寫服務
• 從庫，提供數據庫讀服務
• 主從之間，通過某種機制同步數據，例如mysql的binlog

一個組從同步集群通常稱為一個“分組”。

2. 分組架構究竟解決什么問題?

答：大部分互聯網業務讀多寫少，數據庫的讀往往***成為性能瓶頸，如果希望：

• 線性提升數據庫讀性能
• 通過消除讀寫鎖沖突提升數據庫寫性能

此時可以使用分組架構。

一句話，分組主要解決“數據庫讀性能瓶頸”問題，在數據庫扛不住讀的時候，通常讀寫分離，通過增加從庫線性提升系統讀性能。

二、水平切分

1. 什么是數據庫水平切分?

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

• 每個數據庫之間沒有數據重合，沒有類似binlog同步的關聯
• 所有數據并集，組成全部數據
• 會用算法，來完成數據分割，例如“取模”

一個水平切分集群中的每一個數據庫，通常稱為一個“分片”。

2. 水平切分架構究竟解決什么問題?

答：大部分互聯網業務數據量很大，單庫容量容易成為瓶頸，如果希望：

• 線性降低單庫數據容量
• 線性提升數據庫寫性能

此時可以使用水平切分架構。

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

三、為什么不喜歡讀寫分離

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

• 數據庫連接池需要區分：讀連接池，寫連接池
• 如果要保證讀高可用，讀連接池要實現故障自動轉移
• 有潛在的主庫從庫一致性問題



• 如果面臨的是“讀性能瓶頸”問題，增加緩存可能來得更直接，更容易一點
• 關于成本，從庫的成本比緩存高不少
• 對于云上的架構，以阿里云為例，主庫提供高可用服務，從庫不提供高可用服務

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

當然，使用緩存架構的潛在問題：如果緩存掛了，流量全部壓到數據庫上，數據庫會雪崩。不過幸好，云上的緩存一般都提供高可用的服務。

四、總結

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

你有沒有用讀寫分離，你的思考是什么呢?

【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】

戳這里，看該作者更多好文