讀寫分離是為了將對(duì)數(shù)據(jù)庫的讀、寫分散到不同的數(shù)據(jù)庫實(shí)例上。這樣的設(shè)計(jì)并不一定是完美的。讀寫分離主要針對(duì)的是讀多寫少的場景，對(duì)于寫多讀少的場景就不合適了。比如，持久化落庫就是一個(gè)寫多讀少的場景，多數(shù)情況是在不斷的將數(shù)據(jù)記錄到數(shù)據(jù)庫，偶爾才需要去查詢一下，相當(dāng)于歸檔，大多數(shù)數(shù)據(jù)可能都不會(huì)被訪問到。當(dāng)然，大多數(shù)應(yīng)用都有讀多寫少的特性，這也使得讀寫分離具有廣泛的應(yīng)用場景。

圖片

多數(shù)情況下，我們的讀寫分離都是采用一主多從的架構(gòu)，也就是一臺(tái)主數(shù)據(jù)庫負(fù)責(zé)寫入操作，其他數(shù)據(jù)庫負(fù)責(zé)讀取操作。主數(shù)據(jù)庫和其他數(shù)據(jù)庫之間會(huì)進(jìn)行數(shù)據(jù)同步，這種同步是準(zhǔn)實(shí)時(shí)的。既然是準(zhǔn)實(shí)時(shí)，說明還是有一個(gè)時(shí)間差，這個(gè)時(shí)間差導(dǎo)致了主庫和從庫的數(shù)據(jù)不一致。

那么如何處理這種不一致情況呢？通常有 3 個(gè)思路：

• 將讀請(qǐng)求交給主庫

顯然，從庫沒有我想要的數(shù)據(jù)，我們就可以從主庫讀取，不同的框架都提供強(qiáng)制走主庫的 API 支持。這是比較主流的一種做法，但是這種方法增加了主庫的壓力，相當(dāng)于讀寫分離一定程度上失效了。

• 延遲讀取

有一個(gè)不用動(dòng)腦子的方法，就是讓程序 sleep 一段時(shí)間之后再去讀數(shù)據(jù)，通常主從之間的時(shí)間差不會(huì)差太大，都是毫秒級(jí)別的。

• 業(yè)務(wù)規(guī)避
  上面的兩個(gè)技術(shù)方案并不是很完美，最合適的方案是在業(yè)務(wù)層面繞開這種可能依賴主從數(shù)據(jù)同步的場景，比如，我們可以在完成寫入請(qǐng)求之后，避免立即進(jìn)行請(qǐng)求操作。幸運(yùn)的是，這種場景并不多見，多數(shù)情況下，我們可以天然的規(guī)避這些操作。

如何實(shí)現(xiàn)讀寫分離？

那么說了這么多，如何實(shí)現(xiàn)讀寫分離呢？其實(shí)很多現(xiàn)成的框架組件都幫我們做好了，無論使用哪個(gè)框架，它們的原理都是一樣的，基本都是以下 3 步：

1. 首先部署多個(gè) MySQL 實(shí)例，選擇其中一臺(tái)作為主庫；
2. 保證主從數(shù)據(jù)庫是準(zhǔn)實(shí)時(shí)同步；
3. 將寫請(qǐng)求分給主庫，讀請(qǐng)求分給從庫。

其中比較著名的是官方的 MySQL Router 以及阿里的 MyCat。它們都是獨(dú)立部署的比較重要的中間件。實(shí)際上是在程序和 MySQL 中間加了一個(gè)代理層。應(yīng)用程序?qū)⑺械恼?qǐng)求都交給代理層處理，由代理層負(fù)責(zé)分發(fā)讀寫請(qǐng)求，將它們路由到對(duì)應(yīng)的數(shù)據(jù)庫中。

圖片

更常見的做法是直接引入一個(gè) Jar 包，這個(gè)包允許你配置多個(gè)表，主從數(shù)據(jù)庫地址等等，這樣就不需要部署獨(dú)立的中間件了，簡化了開發(fā)和運(yùn)維的成本，其中比較著名的是 Sharding-JDBC，這個(gè)比較推薦，很多大廠都在使用。

下面我們聊聊讀寫分離的核心——主從同步。主從同步主要是通過 MySQL binlog 日志來進(jìn)行的，binlog 主要記錄了 MySQL 數(shù)據(jù)庫中數(shù)據(jù)的所有 DDL 和 DML 操作。因此，我們根據(jù)主庫的 binlog 日志就可以把數(shù)據(jù)同步到其他數(shù)據(jù)庫實(shí)例中。咱們貼一個(gè)來自國外 toptal 平臺(tái)的文章《MySQL Master-Slave Replication on the Same Machine》的圖：

圖片

上面的過程是這樣的：

• 從庫創(chuàng)建一個(gè) I/O 線程向主庫請(qǐng)求更新的 binlog；
• 主庫創(chuàng)建一個(gè) binlog dump 線程來發(fā)送 binlog；
• 從庫的 I/O 線程將接收的 binlog 寫入到 relay log 中（這里的 relay log 和 binlog 格式類似，下面我們會(huì)講到，在這里大家當(dāng)成是另一個(gè) binlog 就好）；
• 從庫讀取 relay log 同步到本地，通過 SQL 線程在本地執(zhí)行里面的內(nèi)容。

通過上面的分析，咱們可以很明顯地看出來，由于 binlog 包含了所有 DDL 和 DML 操作，因此 binlog 除了可以用于主從復(fù)制，還可以恢復(fù)數(shù)據(jù)，是一個(gè)多功能的文件。上面提到的 I/O 線程和 SQL 線程可以看作是在從庫上工作的 2 個(gè)流水線工人，I/O 線程負(fù)責(zé)原材料的運(yùn)輸，寫入本地的 relay log 中，SQL 線程負(fù)責(zé)從 relay log 獲取原材料并加工。

上面我們提到了 relay log 的格式和 binlog 非常相似，那么為什么需要 relay log 呢？relay log 中文翻譯為“中繼日志”，中繼的意思是橋梁紐帶，除了數(shù)據(jù)本身以外 relay log 內(nèi)部還包含了一些子文件，這些文件記錄了上一次讀取到主庫同步過來的 binlog 的位置，復(fù)制的進(jìn)度以及連接主庫的配置信息等等。

很多三方工具可以幫助我們實(shí)現(xiàn) MySQL 和其他數(shù)據(jù)庫或者另外一臺(tái) MySQL 數(shù)據(jù)庫之間的數(shù)據(jù)同步。大多數(shù)情況下，這些三方工具的底層原理都是基于 binlog。它們的原理就是在模擬 MySQL 主從復(fù)制的過程，解析 binlog 將數(shù)據(jù)同步到其他的數(shù)據(jù)源。

除了 MySQL，比如咱們常用的分布式 NoSQL、緩存 Redis 等，也通過主從復(fù)制實(shí)現(xiàn)了讀寫分離。

總結(jié)

今天我們聊了 MySQL 的讀寫分離，讀寫分離幾乎在所有大并發(fā)的場景得到了運(yùn)用。主寫從讀已經(jīng)成為一個(gè)很普遍的技術(shù)場景。讀寫分離給我們帶來方便的同時(shí)，我們也要注意主從同步的延時(shí)。通?？梢酝ㄟ^ API 強(qiáng)制走主庫來避免這個(gè)問題，但是這就相當(dāng)于沒有做讀寫分離，更好的方案是在業(yè)務(wù)上避免這種操作，比如不要在插入之后立刻讀取。

我們討論了讀寫分離的原理和市面上常用的工具，雖然有很多中間件很有名，但是大廠還是用 Sharding-JDBC 最多，因?yàn)?Sharding-JDBC 輕量、幾乎無侵入。最后我們了解了一下主從復(fù)制的流程，這個(gè)流程只有 4 步，非常簡單。