本課時我們來探討讀寫分離如何在業(yè)務(wù)中落地。

讀寫分離是業(yè)務(wù)開發(fā)中常用的技術(shù)手段，在面試中也是熱點(diǎn)問題，今天我們要講的是在什么業(yè)務(wù)場景下需要讀寫分離，讀寫分離實(shí)現(xiàn)的機(jī)制，以及實(shí)際生產(chǎn)中應(yīng)用讀寫分離要注意的問題。

什么時候需要讀寫分離

互聯(lián)網(wǎng)大部分業(yè)務(wù)場景都是讀多寫少的，對于電商等典型業(yè)務(wù)，讀和寫的請求對比可能差了不止一個數(shù)量級。為了不讓數(shù)據(jù)庫的讀成為業(yè)務(wù)瓶頸，同時也為了保證寫庫的成功率，一般會采用讀寫分離的技術(shù)來保證。

讀寫分離顧名思義，就是分離讀庫和寫庫操作，從 CRUD 的角度，主數(shù)據(jù)庫處理新增、修改、刪除等事務(wù)性操作，而從數(shù)據(jù)庫處理 SELECT 查詢操作。具體的實(shí)現(xiàn)上，可以有一主一從，一個主庫配置一個從庫；也可以一主多從，也就是一個主庫，但是配置多個從庫，讀操作通過多個從庫進(jìn)行，支撐更高的讀并發(fā)壓力。

讀寫分離的實(shí)現(xiàn)是把訪問的壓力從主庫轉(zhuǎn)移到從庫，特別在單機(jī)數(shù)據(jù)庫無法支撐并發(fā)讀寫，并且業(yè)務(wù)請求大部分為讀操作的情況下。如果業(yè)務(wù)特點(diǎn)是寫多讀少，比如一些需要動態(tài)更新的業(yè)務(wù)場景，應(yīng)用讀寫分離就不合適了，由于 MySQL InnoDB 等關(guān)系型數(shù)據(jù)庫對事務(wù)的支持，使得寫性能不會太高，一般會選擇更高性能的 NoSQL 等存儲來實(shí)現(xiàn)。

MySQL 主從復(fù)制技術(shù)

讀寫分離是基于主從復(fù)制架構(gòu)實(shí)現(xiàn)的，下面介紹一下 MySQL 中的主從復(fù)制技術(shù)。

binlog 日志

MySQL InnoDB 引擎的主從復(fù)制，是通過二進(jìn)制日志 binlog 來實(shí)現(xiàn)。除了數(shù)據(jù)查詢語句 select 以外，binlog 日志記錄了其他各類數(shù)據(jù)寫入操作，包括 DDL 和 DML 語句。

binlog 有三種格式：Statement、Row 及 Mixed。

• Statement 格式，基于 SQL 語句的復(fù)制

在 Statement 格式中，binlog 會記錄每一條修改數(shù)據(jù)的 SQL 操作，從庫拿到后在本地進(jìn)行回放就可以了。

• Row 格式，基于行信息復(fù)制

Row 格式以行為維度，記錄每一行數(shù)據(jù)修改的細(xì)節(jié)，不記錄執(zhí)行 SQL 語句的上下文相關(guān)的信息，僅記錄行數(shù)據(jù)的修改。假設(shè)有一個批量更新操作，會以行記錄的形式來保存二進(jìn)制文件，這樣可能會產(chǎn)生大量的日志內(nèi)容。

• Mixed 格式，混合模式復(fù)制

Mixed 格式，就是 Statement 與 Row 的結(jié)合，在這種方式下，不同的 SQL 操作會區(qū)別對待。比如一般的數(shù)據(jù)操作使用 row 格式保存，有些表結(jié)構(gòu)的變更語句，使用 statement 來記錄。

主從復(fù)制過程

MySQL 主從復(fù)制過程如下圖所示：

• 主庫將變更寫入 binlog 日志，從庫連接到主庫之后，主庫會創(chuàng)建一個log dump 線程，用于發(fā)送 bin log 的內(nèi)容。

• 從庫開啟同步以后，會創(chuàng)建一個 IO 線程用來連接主庫，請求主庫中更新的 bin log，I/O 線程接收到主庫 binlog dump 進(jìn)程發(fā)來的更新之后，保存在本地 relay 日志中。

• 接著從庫中有一個 SQL 線程負(fù)責(zé)讀取 relay log 中的內(nèi)容，同步到數(shù)據(jù)庫存儲中，也就是在自己本地進(jìn)行回放，最終保證主從數(shù)據(jù)的一致性。

讀寫分離要注意的問題

分布式系統(tǒng)通過主從復(fù)制實(shí)現(xiàn)讀寫分離，解決了讀和寫操作的性能瓶頸問題，但同時也增加了整體的復(fù)雜性。我們看一下引入主從復(fù)制后，額外需要注意哪些問題。

主從復(fù)制下的延時問題

由于主庫和從庫是兩個不同的數(shù)據(jù)源，主從復(fù)制過程會存在一個延時，當(dāng)主庫有數(shù)據(jù)寫入之后，同時寫入 binlog 日志文件中，然后從庫通過 binlog 文件同步數(shù)據(jù)，由于需要額外執(zhí)行日志同步和寫入操作，這期間會有一定時間的延遲。特別是在高并發(fā)場景下，剛寫入主庫的數(shù)據(jù)是不能馬上在從庫讀取的，要等待幾十毫秒或者上百毫秒以后才可以。

在某些對一致性要求較高的業(yè)務(wù)場景中，這種主從導(dǎo)致的延遲會引起一些業(yè)務(wù)問題，比如訂單支付，付款已經(jīng)完成，主庫數(shù)據(jù)更新了，從庫還沒有，這時候去從庫讀數(shù)據(jù)，會出現(xiàn)訂單未支付的情況，在業(yè)務(wù)中是不能接受的。

為了解決主從同步延遲的問題，通常有以下幾個方法。

• 敏感業(yè)務(wù)強(qiáng)制讀主庫

在開發(fā)中有部分業(yè)務(wù)需要寫庫后實(shí)時讀數(shù)據(jù)，這一類操作通?？梢酝ㄟ^強(qiáng)制讀主庫來解決。

• 關(guān)鍵業(yè)務(wù)不進(jìn)行讀寫分離

對一致性不敏感的業(yè)務(wù)，比如電商中的訂單評論、個人信息等可以進(jìn)行讀寫分離，對一致性要求比較高的業(yè)務(wù)，比如金融支付，不進(jìn)行讀寫分離，避免延遲導(dǎo)致的問題。

主從復(fù)制如何避免丟數(shù)據(jù)

假設(shè)在數(shù)據(jù)庫主從同步時，主庫宕機(jī)，并且數(shù)據(jù)還沒有同步到從庫，就會出現(xiàn)數(shù)據(jù)丟失和不一致的情況，雖然這是一個極端場景，一般不會發(fā)生，但是 MySQL 在設(shè)計時還是考慮到了。

MySQL 數(shù)據(jù)庫主從復(fù)制有異步復(fù)制、半同步復(fù)制和全同步復(fù)制的方式。

• 異步復(fù)制

異步復(fù)制模式下，主庫在接受并處理客戶端的寫入請求時，直接返回執(zhí)行結(jié)果，不關(guān)心從庫同步是否成功，這樣就會存在上面說的問題，主庫崩潰以后，可能有部分操作沒有同步到從庫，出現(xiàn)數(shù)據(jù)丟失問題。

• 半同步復(fù)制

在半同步復(fù)制模式下，主庫需要等待至少一個從庫完成同步之后，才完成寫操作。主庫在執(zhí)行完客戶端提交的事務(wù)后，從庫將日志寫入自己本地的 relay log 之后，會返回一個響應(yīng)結(jié)果給主庫，主庫確認(rèn)從庫已經(jīng)同步完成，才會結(jié)束本次寫操作。相對于異步復(fù)制，半同步復(fù)制提高了數(shù)據(jù)的安全性，避免了主庫崩潰出現(xiàn)的數(shù)據(jù)丟失，但是同時也增加了主庫寫操作的耗時。

• 全同步復(fù)制

全同步復(fù)制指的是在多從庫的情況下，當(dāng)主庫執(zhí)行完一個事務(wù)，需要等待所有的從庫都同步完成以后，才完成本次寫操作。全同步復(fù)制需要等待所有從庫執(zhí)行完對應(yīng)的事務(wù)，所以整體性能是最差的。

總結(jié)

今天分享了讀寫分離的業(yè)務(wù)場景，MySQL 的主從復(fù)制技術(shù)，包括 binlog 的應(yīng)用、主從復(fù)制的延時問題、數(shù)據(jù)庫同步的不同機(jī)制等。

讀寫分離只是分布式性能優(yōu)化的一個手段，不是任何讀性能瓶頸都需要使用讀寫分離，除了讀寫分離，還可以進(jìn)行分庫分表，以及利用緩存，文件索引等 NoSQL 數(shù)據(jù)庫來提高性能，這些內(nèi)容在后面的課時中會講到。