當業務發展到一定階段，數量上去之後，數據庫可能會成為性能的瓶頸。此時就需要一些架構調整去優化數據庫的訪問，而數據庫的讀寫分離就是其中的一種手段。不過要注意的是讀寫分離會增加系統的複雜性。在使用讀寫分離之前，先進行單機優化，比如sql語句的優化，表設計的優化或者增加緩存等。在充分利用單機性能之後，再考慮讀寫分離。另外，讀寫分離也是有適用場景的。
數據庫讀寫分離適用於讀多寫少的場景。整體的架構思路是，將數據庫的讀和寫拆分開，數據庫整體以一臺主庫負責寫請求，多臺從庫負責讀請求的方式對外提供服務。這樣，在大量讀的業務中，可以利用增加從庫的方式擴展數據庫讀的性能。但是如果業務的寫請求量也很大，那麼寫請求依然存在瓶頸。為什麼我們不提供多臺服務器進行寫呢？這裡面涉及一致性的問題。在多個庫支持寫時，數據很難保持一致性，很可能存在數據的覆蓋。
讀寫分離架構
讀寫分離還具有這些特點，用的時候需要注意。寫請求是直接落在主庫上，主庫再同步給從庫。這樣就會存在一個問題，用戶更新了數據之後，馬上去查，可能這個時候數據還沒有同步到從庫，看不到更新的數據。對於這個問題，可以從如下幾個方向去考慮解決：
1.對於同一個用戶，寫之後的訪問也落在主庫上，這樣可以保證更新的數據一定能被查詢上來。但是這麼設計可擴展性不是很好。
2.“雙讀”。在讀取插入的數據時，如果第一次沒有查詢到結果，就去主庫再查一遍。這種方法不安全，容易被黑客利用。當查詢大量不存在的數據的時候，會導致主庫性能下降。
3.業務拆分，對於可以容忍的業務從從庫讀取，而不能容忍延遲更新的業務，在更新之後從主庫讀數據。
對於讀寫分離之後的數據庫訪問，有兩種方式，一種是在客戶端中增加邏輯，判斷是讀還是寫，再訪問不同的數據庫。另一種方式是提供一個代理服務，服務器統一訪問代理，由代理進行請求的分發。
客戶端模式
代理模式
閱讀更多 java技術小碼農 的文章
