產生原因
一般做數據庫讀寫分離的時候，都是由於數據庫扛不住用戶的大量請求，導致數據庫出現瓶頸，爲了增大數據庫的吞吐量而做的。那麼當一個請求往主庫裏面寫的時候，同時會同步一份數據寫到從庫中。如果此時從庫處於非常繁忙的狀態，就會出現主庫的數據沒法及時同步到從庫，從庫無法查詢到更新的數據。就產生了主從延遲。
治標方案
一、針對網上的很多方案不外乎就是什麼更改優化數據庫配置，提升從庫數據庫服務器的配置。這兩種方式都可以適當的降低主從延遲的時間。但是都沒辦法從根本上解決這個問題，當用戶的量達到服務器配置的瓶頸的時候，主從延遲還是會出現，治標不治本。
二、在mysql5.6之前，主從複製採用的都是單線程的複製。mysql官方在5.6之後加入了並行複製的功能，如果您採用的數據庫版本是5.6之前的，也可以採用升級mysql數據庫版本的方法。
三、另外如果上述方案都採用了之後仍然出現主從延遲，那麼可以我們從主從延遲的原因產生上面可以知道，既然一個從庫無法抗住壓力，那麼我們可以增加多個從庫，比如2個3個從庫，這樣分攤一個從庫的壓力，也可以處理主從延遲的問題。
治本方案
上述方案都可以有效的處理主從延遲的問題。但是處理問題的根本思路都是減少主從延遲的時間，來達到不影響業務處理時間的目的，從而消除主從延遲的影響。那麼現在我們考慮一個情況，就是不論您如何處理優化，當用戶請求量達到您的數據庫處理瓶頸的時候，主從延遲是必然出現的。這是數據庫本身的設計決定的。除非您可以修改數據庫的源碼，更改數據庫主從同步的實現方式。比如加入同步中間件，或者採用某些機制，確保主從同步完成纔給用戶返回處理成功等，當然這樣顯然也會導致一些性能的損耗。那麼在目前的這種我們無法去修改數據庫源碼，或者說大多數公司都沒有這個實力去做這個事情的情況下，我的解決方案是：
一、首先，假如你的業務時間允許，你可以在寫入主庫的時候，確保數據都同步到從庫了之後才返回這條數據寫入成功，當然如果有多個從庫，你也必須確保每個從庫都寫入成功。顯然，這個方案對性能和時間的消耗是極大的，不推薦。
二、另外一種就是，可以引入redis或者其他nosql數據庫來存儲我們經常會產生主從延遲的業務數據。當我在寫入數據庫的同時，我再寫入一份到redis中。然後用戶去讀取數據的時候發現沒有讀取到這個數據，那麼我們就可以再去查看redis中是否有這個數據，如果有我們就可以直接從redis中讀取這個數據。當數據真正同步到數據庫中的時候，再從redis中把數據刪除。
三、任何的服務器都是有吞吐量的限制的，沒有任何一個方案可以無限制的承載用戶的大量流量。所以我們必須估算好我們的服務器能夠承載的流量上限是多少。達到這個上限之後，就要採取緩存，限流，降級的這三大殺招來應對我們的流量。這也是應對主從延遲的根本處理辦法。
四、既然主從延遲是由於從庫寫庫不及時引起的，那我們也可以在有主從延遲的地方改變讀庫方式，由原來的讀從庫改爲讀主庫。當然這也會增加代碼的一些邏輯複雜性。
想學習分佈式、微服務、JVM、多線程、架構、java、python的童鞋，千萬不要掃碼，否則後果自負~
林老師帶你學編程：https://wolzq.com