現在絕大部分軟件項目，都會使用到關系型數據庫，比如MySQL、Oracle、DB2等等，目前這些數據庫的單機性能已經是不斷優化和提高了，但是隨著數據增長的速度和并發訪問量的增加，在某些公司、某些場景下，單機數據庫已經很難滿足業務的需要了，所以必須考慮數據庫集群的方式來提高系統的可用性；最常見的兩種方法：

分庫分表：把數據分散到不同的數據庫上，每臺數據庫中存儲的數據是不相同的（這里先不考慮每個庫做備份或讀寫分離）；分庫分表既可以分散數據庫訪問的壓力，也可以分散數據存儲的壓力；但是使用分庫分表方案的時候，會帶來擴容、事務、關聯查詢等問題和難點，具體這里就不展開講了。

讀寫分離：將數據庫讀操作和寫操作分散到不同的節點上，通常是一臺數據庫做寫操作，1到N臺做讀操作；讀寫分離的架構，每一臺數據中的數據是相同的（這里先忽略延遲的問題），所以只分散了數據庫訪問的壓力，并沒有分散數據存儲的壓力；我們這里主要講一講讀寫分離。

讀寫分離基本架構

MySQL讀寫分離的基本架構，可以參考下圖：

如上圖，讀寫分離實現的基本步驟是：

數據庫服務器搭建多臺，一主N從（N大于等于1）；

主數據庫只負責寫操作，從數據庫只負責讀操作；

主數據庫復制數據到從數據庫上；

客戶端寫操作路由到主數據庫上，讀操作路由到從數據庫上。

讀寫分離還有另外一種架構，就是在MySQL數據庫和客戶端之間，增加一層中間代理層，客戶端只連接代理， 由代理根據請求類型，把請求分發到不同的數據庫上：

第一種架構，整體架構比較簡單直接，性能會稍微高一些，但是如果才用直連的方式，客戶端可能會稍微麻煩一些（通常需要引入一些組件，負責管理數據庫）；

第二種架構，對客戶端比較友好，因為客戶端只需要和代理交互，并不用關注數據庫的具體信息；但是因為多了一層代理，多多少少會對性能有一定的影響。

讀寫分離帶來的好處

讀寫分離結構中，會有兩臺甚至更多臺數據庫，這種冗余的設計，可以提高數據的安全性和系統的可用性；就算是在分庫分表的架構中，每一臺子庫，也可以一主多備的部署方式；

讀寫分離更多的時候使用在讀操作遠遠大于寫操作的場景下，這樣可以保證寫操作的數據庫承受更小的壓力，也可以緩解X鎖和S鎖爭用；

服務器數量的增加，意味著可以有效地利用多臺服務器的資源；讀操作被分攤，提高了系統的性能；

如果寫操作比讀操作多，或者相近，可以采用雙主相互復制的架構。

讀寫分離會帶來的問題

之前的文章，我也反復強調過，任何的架構、軟件、框架、組件...在解決一部分問題的時候，一定會帶來其他的問題；讀寫分離最大的一個問題就是，數據從主復制到從的過程中，可能會存在延遲的，如果客戶端在執行完一個讀操作后，立刻從存庫中查詢的話，可能會讀取到舊數據的情況（我們不斷優化，也只能縮短這個時間，并不能完全消除掉這個時間）。

那么針對這個問題，有哪些處理方法呢？

根據具體場景進行評估，是否可以接收這個延遲（這好像是一句廢話，但是大多數業務場景，是可以接收這點兒延遲的）；

對于實時性要求很高的場景（查詢的數據必須是最新的結果），將這些請求強制路由到主庫上；

執行完寫操作之后，在讀操作發生之前，讓中間的時間變長（也就是從業務操作角度來做一些控制，不一定操作完了立刻查詢）；

判斷主備無延遲，可以通過判斷seconds_behind_master參數、對比GTID、對比位點等方式，判斷從數據庫是否和主數據庫一致。