一、如何正確使用數據庫讀寫分離
1、背景
在應用系統發展的初期，我們並不知道以后會發展成什么樣的規模，所以一開始不會考慮復雜的系統架構，復雜的系統架構費時費力，開發周期長，與系統發展初期這樣的一個定位是不吻合的。所以，我們都會采用簡單的架構，隨着業務不斷的發展，訪問量不斷升高，我們再對系統進行架構方面的優化。
2、架構演進
系統建立初期，我們的架構都非常的簡單，主要滿足業務的正常運行，如圖：
但是隨着訪問量的升高，人們對系統的可靠性有了更高的要求，所以，我們為了避免單點故障，對系統應用層進行了橫向的擴展，如圖：
這樣，保證了系統應用層的高可用，在發生宕機，或者系統升級時，系統對外還是可用的。而且在訪問量升高的時候，系統應用層的壓力也會得到分攤，使得每一個單體的系統應用的壓力在一個合理的區間范圍內。
但是，隨着訪問量的升高，所有的壓力都將集中到數據庫這一層。那么數據庫這一層，我們要怎么處理呢？能不能像系統應用層那樣進行擴展呢？答案當然時否定的，我們想象一下，如果數據庫層也像系統應用層那樣，進行橫向擴展，如圖：
那么，如果系統應用層產生了一條數據，這條數據應該插入到DB1還是DB2呢？假設插入了DB1，那么這條數據被讀取時，應用層怎么知道從哪個數據庫讀取這條數據呢？問題是不是很復雜，如果數據庫不進行擴展，那么一台數據庫是承載不了這么大的訪問量的，那我們怎么辦呢？
二、數據庫讀寫分離
辦法總比問題多，隨着互聯網技術的發展，以及一代代互聯網人對互聯網的深入研究，人們發現在互聯網的系統應用是一個讀多寫少的應用，比如咱們課程中的電商系統，商品瀏覽的次數是比下單要多的。數據庫承載壓力大，主要是由這些讀的請求造成的，那么我們是不是可以把讀操作和寫操作分開，讓所有讀的請求落到專門負責讀的數據庫上，所有寫的操作落到專門負責寫的數據庫上，寫庫的數據同步到讀庫上，這樣保證所有的數據修改都可以在讀取時，從讀庫獲得，系統的架構如圖所示：
如果系統的讀請求比較多的話，讀庫可以多部署幾台，這樣讀請求就可以均攤到多台讀庫上，降低每一個讀庫上的壓力。但是在寫數據的時候，數據要落在一個確定，且唯一的寫庫中。上圖中，咱們的寫庫只有一個，你當然可以部署多個寫庫，但是數據怎么分片是一個十分重要的問題，這個問題我們在后續的課程中會給大家做介紹。目前僅以一個寫庫為例，比如：商戶發布商品時，將這個商品的數據落在了寫庫上，同時，寫庫將這條數據同步給兩個讀庫，買家在網站瀏覽商品時，會從讀庫將這個商品數據讀取。至於從哪個讀庫取出數據，那就要看這個請求在當時的路由情況了。
總之，將大量的讀操作從數據庫中剝離，讓讀操作從專用的讀數據庫中讀取數據，大大緩解了數據庫的訪問壓力，也使得讀取數據的響應速度得到了大大的提升。那么讀寫分離有什么弊端嗎？是不是所有的場景都適用讀寫分離這種架構呢？
三、讀寫分離的弊端
讀寫分離給我們帶來的好處是很多的，我們對比一下原始的架構和讀寫分離的架構，從數據流上看，他們的區別是，數據從寫入到數據庫，到從數據庫取出，讀寫分離的架構多了一個同步的操作。大家想一想，同步操作的時間是多少，延遲如果太大對系統有沒有影響，如果同步掛了怎么辦？老師舉一個親身經歷的案例，那時老師在做個人中心的訂單列表頁，這個功能挺簡單，只需要把訂單數據取出來，在頁面上展示就可以了。但是在做的時候，訂單以及訂單相關的數據都是從讀庫取出的，其中就包括支付狀態，這個用戶非常敏感的字段。就在某一天的某一個時段，突然接到了用戶大量的投訴，說用戶已經付了錢了，但是訂單的狀態還是未支付。我也覺得很奇怪，馬上要了一個訂單號，去數據庫里查詢，發現訂單狀態就是未支付呀，沒有問題，過了一會，為了保險起見，我還是去寫庫再查一下這個訂單吧，發現寫庫的訂單狀態確實是已支付，這下完了，寫庫和讀取的數據不一致，我馬上通知DBA，讓他去查數據庫，他的反饋是同步掛掉了。
大家看到了吧，這就是讀寫分離的弊端，當同步掛掉，或者同步延遲比較大時，寫庫和讀庫的數據不一致，這個數據的不一致，用戶能不能接受，訂單支付狀態這個不一致當然是不能接受的了，其他的業務場景能不能接受呢？這個要對不同的業務場景做具體的分析了。
四、如何正確的使用讀寫分離
一些對數據實時性要求不高的業務場景，可以考慮使用讀寫分離。但是對數據實時性要求比較高的場景，比如訂單支付狀態，還是不建議采用讀寫分離的，或者你在寫程序時，老老實實的從寫庫去讀取數據。我也咨詢過專門做數據同步的機構，他們給出的建議是，如果你做數據的同步，你的網絡延遲應該在5ms以內，這個對網絡環境要求是非常高的，大家可以ping一下你網絡中的其他機器，看看能不能達到這個標准。如果你的網絡環境很好，達到了要求，那么使用讀寫分離是沒有問題的，數據幾乎是實時同步到讀庫，根本感覺不到延遲。
讀寫分離呢，就給大家介紹到這，大家在使用的時候，還是要從業務出發，看看你的業務是否適合使用讀寫分離，每種技術架構都有自己的優缺點，沒有好不好，只有適合不適合。只有適合業務的架構才是好的架構。