最近在研究一些系統架構方案，學習到讀寫分離的時候，對於讀寫分離應用場景有了一些自己的理解：

一. 讀寫分離

1. 什麼是資料庫讀寫分離

  首先我們看一個讀寫分離架構圖：

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

• 主庫：提供資料庫寫服務；
• 從庫：提供資料庫讀服務；
• 主從之間：通過某種機制同步資料，比如MySOL的binlog

  一個主從同步的叢集通常稱為一個“分組”，這也是分組這個概念的含義。

2. 分組架構能夠解決的問題

 在大部分網際網路業務場景中，讀操作的比例遠遠大於寫操作，資料庫的讀往往最先成為資料庫的新能瓶頸，如果想要完成下面的目標：

• 線性提升資料庫讀效能；
• 通過消除讀寫鎖衝突提升資料庫寫效能

這兩種期望的業務場景都可以使用分組架構來解決問題。總結來說，分組主要解決的就是“資料庫讀效能瓶頸”問題。在資料庫無法勝任當前的讀要求時，就可以進行讀寫分寫，通過增加從庫線性提升系統讀效能。

二. 水平切分

 1. 水平切分

  水平切分，也是一種常見的資料庫架構，一般來說：

• 每個資料庫之間沒有資料重合，沒有類似binlog同步的關聯；
• 所有資料並集，組成全部資料；
• 會用某些演算法，來完成資料分割，例如取模運算

  一個水平切分急群眾的每個資料庫，通常稱為一個分片。

2. 水平分片架構解決的問題

   大部分網際網路業務資料量很大，單庫容量容易稱為瓶頸，如果希望解決下面的問題：

•  線性降低單庫資料容量；
• 線性提升資料庫寫效能

   這兩種改進要求時可以採用水平分片架構。一般來說，水平分片主要解決資料庫資料量大的問題，在資料庫單庫容量無法滿足系統要求時，我們可以採用水平切分。

三 讀寫分離的不適用性

   對於網際網路，大資料量、高併發量、高可用性、高一致性、前段面向使用者的業務場景，如果資料庫讀寫分離：

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

四. 快取架構

     快取的架構圖如上圖，應用場景包括：

• 如果面臨的是“讀效能瓶頸”問題，增加快取可能來的更直接，更容易一點；
• 關於成本，從庫的成本比快取高了很多；
• 對於雲上的架構，主庫提供高可用服務，從庫不提供高可用服務

  這幾類場景就建議使用快取架構來加強系統讀效能，代替資料庫主從分離架構。當然快取架構的潛在問題：如果快取掛了，流量全部壓到資料庫上，資料庫會雪崩。同樣快取會有快取穿透、快取一致、快取雪崩、快取併發等問題

五.小結

1.  讀寫分離，解決“資料庫讀效能瓶頸”問題；
2. 水平切分，解決“資料庫資料量大”問題；
3. 對於網際網路大資料量、高併發量、高可用要求、高一致性、前段面向使用者的應用場景，微服務快取架構，可能比讀寫分離架構更加合適。