MySQL讀寫分離及主從同步延時問題解決思路深刻剖析-綜合組件環境實戰

本套技術專欄是做者（秦凱新）平時工做的總結和昇華，並深度整理大量網上資源和專業書籍。經過從真實商業環境抽取案例進行總結和分享，並給出商業應用的調優建議和集羣環境容量規劃等內容，請持續關注本套博客。QQ郵箱地址：1120746959@qq.com，若有任何學術交流，可隨時聯繫。

1 MySQL 讀寫分離機制

• 單庫最高承受的讀寫能力通常上限爲2000/s

• mysql的讀寫分離就是根據業務場景設計一個主庫，掛多個從庫，而後咱們就單單只是寫主庫，而後主庫會自動把數據給同步到從庫，這樣將一個主庫拆分爲4個主庫，每一個主庫的寫併發就500/s，此時主從延遲能夠忽略不計。

1.1 MySQL內核主從同步原理

• 主庫將變動寫binlog日誌，而後從庫鏈接到主庫以後，從庫有一個IO線程，將主庫的binlog日誌拷貝到本身本地，寫入一箇中繼日誌（RelayLog）中。接着從庫中有一個SQL線程會從中繼日誌（RelayLog）讀取binlog，而後執行binlog日誌中的內容，也就是在本身本地再次執行一遍SQL，這樣就能夠保證本身跟主庫的數據是同樣的。

1.2 主從複製可能存在的問題

• 用了mysql主從架構以後，可能會發現，由於延時問題剛寫入庫的數據結果沒查到。

• 從庫同步主庫數據的過程是串行化的，也就是說主庫上並行的操做，在從庫上會串行執行。因此這就是一個很是重要的點了，因爲從庫從主庫拷貝日誌以及串行執行SQL的特色，在高併發場景下，從庫的數據必定會比主庫慢一些，是有延時的。因此常常出現，剛寫入主庫的數據多是讀不到的，要過幾十毫秒，甚至幾百毫秒才能讀取到。

• 若是主庫忽然宕機，而後剛好數據還沒同步到從庫，那麼有些數據可能在從庫上是沒有的，有些數據可能就丟失了。

1.3 MySQL 主從同步機制

• 半同步複製(semi-sync複製) --> 用來解決主庫數據丟失問題,主庫寫入binlog日誌以後，就會將強制此時當即將數據同步到從庫，從庫將日誌寫入本身本地的relay log以後，接着會返回一個ack給主庫，主庫接收到至少一個從庫的ack以後纔會認爲寫操做完成了。
• 並行複製 --> 指的是從庫開啓多個線程，並行讀取relay log中不一樣庫的日誌，而後並行重放不一樣庫的日誌，這是庫級別的並行。

1.4 使用場景

• 通常在讀遠遠多於寫，並且讀的時候通常對數據時效性要求沒那麼高的時候，用mysql主從同步。

2 主從延遲嚴重時處理思路

• 分庫，將一個主庫拆分爲成多個主庫，此時主從延遲能夠忽略不計
• 打開mysql支持的並行複製，多個庫並行複製，若是說某個庫的寫入併發就是特別高，單庫寫併發達到了2000/s，並行複製沒意義。
• 重寫代碼，寫代碼要慎重，，插入數據以後，直接就更新，不要查詢
• 若是確實是存在必須先插入，立馬要求就查詢到，而後立馬就要反過來執行一些操做，對這個查詢設置直連主庫。不推薦這種方法，你這麼搞致使讀寫分離的意義就喪失了。

3 總結

結合大數據在咱們工業大數據平臺的實踐，總結成一篇實踐指南，方便之後查閱反思，後續我會根據本篇博客進行代碼技術實踐實現。

凱新雲技術社區