面試39 MySQL讀寫分離

（1）如何實現mysql的讀寫分離？

?

其實很簡單，就是基于主從復制架構，簡單來說，就搞一個主庫，掛多個從庫，然后我們就單單只是寫主庫，然后主庫會自動把數據給同步到從庫上去。

?

（2）MySQL主從復制原理的是啥？

?

主庫將變更寫binlog日志，然后從庫連接到主庫之后，從庫有一個IO線程，將主庫的binlog日志拷貝到自己本地，寫入一個中繼日志中。接著從庫中有一個SQL線程會從中繼日志讀取binlog，然后執行binlog日志中的內容，也就是在自己本地再次執行一遍SQL，這樣就可以保證自己跟主庫的數據是一樣的。

?

這里有一個非常重要的一點，就是從庫同步主庫數據的過程是串行化的，也就是說主庫上并行的操作，在從庫上會串行執行。所以這就是一個非常重要的點了，由于從庫從主庫拷貝日志以及串行執行SQL的特點，在高并發場景下，從庫的數據一定會比主庫慢一些，是有延時的。所以經常出現，剛寫入主庫的數據可能是讀不到的，要過幾十毫秒，甚至幾百毫秒才能讀取到。

?

而且這里還有另外一個問題，就是如果主庫突然宕機，然后恰好數據還沒同步到從庫，那么有些數據可能在從庫上是沒有的，有些數據可能就丟失了。

?

所以mysql實際上在這一塊有兩個機制，一個是半同步復制，用來解決主庫數據丟失問題；一個是并行復制，用來解決主從同步延時問題。

?

這個所謂半同步復制，semi-sync復制，指的就是主庫寫入binlog日志之后，就會將強制此時立即將數據同步到從庫，從庫將日志寫入自己本地的relay log之后，接著會返回一個ack給主庫，主庫接收到至少一個從庫的ack之后才會認為寫操作完成了。

?

所謂并行復制，指的是從庫開啟多個線程，并行讀取relay log中不同庫的日志，然后并行重放不同庫的日志，這是庫級別的并行。

1）主從復制的原理

2）主從延遲問題產生的原因

3）主從復制的數據丟失問題，以及半同步復制的原理

4）并行復制的原理，多庫并發重放relay日志，緩解主從延遲問題

?

（3）mysql主從同步延時問題（精華）

?

線上確實處理過因為主從同步延時問題，導致的線上的bug，小型的生產事故

?

show status，Seconds_Behind_Master，你可以看到從庫復制主庫的數據落后了幾ms

?

其實這塊東西我們經常會碰到，就比如說用了mysql主從架構之后，可能會發現，剛寫入庫的數據結果沒查到，結果就完蛋了。。。。

?

所以實際上你要考慮好應該在什么場景下來用這個mysql主從同步，建議是一般在讀遠遠多于寫，而且讀的時候一般對數據時效性要求沒那么高的時候，用mysql主從同步

?

所以這個時候，我們可以考慮的一個事情就是，你可以用mysql的并行復制，但是問題是那是庫級別的并行，所以有時候作用不是很大

?

所以這個時候。。通常來說，我們會對于那種寫了之后立馬就要保證可以查到的場景，采用強制讀主庫的方式，這樣就可以保證你肯定的可以讀到數據了吧。其實用一些數據庫中間件是沒問題的。

?

一般來說，如果主從延遲較為嚴重

?

1、分庫，將一個主庫拆分為4個主庫，每個主庫的寫并發就500/s，此時主從延遲可以忽略不計

2、打開mysql支持的并行復制，多個庫并行復制，如果說某個庫的寫入并發就是特別高，單庫寫并發達到了2000/s，并行復制還是沒意義。28法則，很多時候比如說，就是少數的幾個訂單表，寫入了2000/s，其他幾十個表10/s。

3、重寫代碼，寫代碼的同學，要慎重，當時我們其實短期是讓那個同學重寫了一下代碼，插入數據之后，直接就更新，不要查詢

如果確實是存在必須先插入，立馬要求就查詢到，然后立馬就要反過來執行一些操作，對這個查詢設置直連主庫。不推薦這種方法，你這么搞導致讀寫分離的意義就喪失了