之前的文章我們提到過，主備數(shù)據(jù)庫是通過binlog實現(xiàn)的數(shù)據(jù)同步：

主庫在接到客戶端更新請求時，執(zhí)行內(nèi)部事務(wù)的更新邏輯，同時寫binlog。 r

1）edo log commit后，才會回復(fù)客戶端ack； 

2）binlog寫成功后就可以同步備庫，因為binlog寫盤成功后，就算后續(xù)commit失敗，數(shù)據(jù)庫也可以根據(jù)redo log+binlog重新恢復(fù)commit狀態(tài)； 

備庫與主庫之間維護一個長鏈接，有專門的線程來發(fā)送或者接收請求。

果凍布丁兔，公眾號：陸隊長MySQL：為什么所有實例可以保證數(shù)據(jù)一致性

無論是主備還是主從，實際上都是為了保證MySQL集群的高可用性：

無論是主備還是主從架構(gòu)，實際上就是為了系統(tǒng)的高可用性實現(xiàn)的一個策略，防止主機因為某些故障導(dǎo)致異常下線，這時候備份或者從實例就會通過選擇或者其他策略成為主服務(wù)實例，對外繼續(xù)提供服務(wù)。

果凍布丁兔，公眾號：陸隊長MySQL：從MySQL看主從架構(gòu)高可用性實現(xiàn)

但是如果在一個壓力持續(xù)比較久（比如雙十一或者大促期間）的主從系統(tǒng)內(nèi)，主服務(wù)器需要應(yīng)對龐大的數(shù)據(jù)讀寫壓力，如果備庫執(zhí)行日志的速度低于主庫生成日志的速度，那么主從的主備延遲時間越來越長，導(dǎo)致備庫可能一直無法追上主庫。這時候就需要本節(jié)引入的備庫并行復(fù)制能力。

圖片

如圖所示的兩個黑色箭頭是我們比較關(guān)注的，一個是客戶端寫入主庫，一個是備庫上sql_thread執(zhí)行中轉(zhuǎn)日志（relay log）。

主庫上影響并發(fā)主要是各種鎖，在備庫上的執(zhí)行，如果 從sql_thread更新數(shù)據(jù)使用單線程就很大可能導(dǎo)致主備延遲，這也是MySQL5.6版本前在主庫并發(fā)高或者TPS高時導(dǎo)致嚴(yán)重主備延遲問題的原因。

圖片

上圖有些類似netty的線程模型，沒錯，如果是好的技術(shù)模型，那么在很多的技術(shù)棧中都會使用。

coordinator只負(fù)責(zé)讀取中轉(zhuǎn)日志和分發(fā)事務(wù)，真正更新日志的邏輯由各個worker線程處理，worker的線程數(shù)由參數(shù)slave_parallel_workers決定。如果是32核的服務(wù)器，這個值可以設(shè)置為8~16.

雖然文章中很多人說為了保證備庫的讀服務(wù)，線程數(shù)為核數(shù)1/4~1/2，實際上我是不認(rèn)同的，應(yīng)該是主要看核數(shù)和讀寫壓力，如果即使是64核的機器，并且寫壓力不大，還是可以繼續(xù)保持當(dāng)前的配置；如果是讀寫比例在10:1，那么這個線程數(shù)可以超過1/2。

為了保證事務(wù)的冪等性和原子性，我們需要做如下的要求：

1.冪等性：不能造成更新覆蓋。冪等性要求同一行的兩個事務(wù)必須分發(fā)到同一個worker。這里主要是為了防止由于客戶端的重試導(dǎo)致的事務(wù)重復(fù)或者是兩個事務(wù)之間的上下文依賴導(dǎo)致的數(shù)據(jù)不一致。

2.原子性：用一個事務(wù)必須由一個worker負(fù)責(zé)。相同事務(wù)的語句必須使用一個worker處理，否則可能導(dǎo)致一個worker失敗，另一個worker成功引入的數(shù)據(jù)不一致問題。

1 并行復(fù)制策略介紹

注意，這部分是作者丁奇自己寫的并行復(fù)制策略，非官方實現(xiàn)策略。

1.1 按表分發(fā)策略

按表分發(fā)事務(wù)的基本思想是：如果兩個事務(wù)更新不同的表，他們就可以并行。因為數(shù)據(jù)是存儲在表里，所以按表分發(fā)，可以保證兩個worker不會更新同一行。

如果有跨表的事務(wù)，那么就需要把兩張表放在一起考慮。

圖片

每個worker對應(yīng)一個hash表，用于保存當(dāng)前正在這個worker的“執(zhí)行隊列”里的事務(wù)所涉及的表。hash表的key是“庫名.表名”，value是一個數(shù)字，表示隊列中有多少事務(wù)修改這個表。

在有事務(wù)分配給 worker 時，事務(wù)里面涉及的表會被加到對應(yīng)的 hash 表中。worker 執(zhí)行完成后，這個表會被從 hash 表中去掉。

圖 3 中，hash_table_1 表示，現(xiàn)在 worker_1 的“待執(zhí)行事務(wù)隊列”里，有 4 個事務(wù)涉及到 db1.t1 表，有 1 個事務(wù)涉及到 db1.t2 表；hash_table_2 表示，現(xiàn)在 worker_2 中有一個事務(wù)會更新到表 t3 的數(shù)據(jù)。

假設(shè)在圖中的情況下，coordinator 從中轉(zhuǎn)日志中讀入一個新事務(wù) T，這個事務(wù)修改的行涉及到表 t1 和 t3。

現(xiàn)在我們用事務(wù) T 的分配流程，來看一下分配規(guī)則：

1. 由于事務(wù) T 中涉及修改表 t1，而 worker_1 隊列中有事務(wù)在修改表 t1，事務(wù) T 和隊列中的某個事務(wù)要修改同一個表的數(shù)據(jù)，這種情況我們說事務(wù) T 和 worker_1 是沖突的。
2. 按照這個邏輯，順序判斷事務(wù) T 和每個 worker 隊列的沖突關(guān)系，會發(fā)現(xiàn)事務(wù) T 跟 worker_2 也沖突。
3. 事務(wù) T 跟多于一個 worker 沖突，coordinator 線程就進入等待。
4. 每個 worker 繼續(xù)執(zhí)行，同時修改 hash_table。假設(shè) hash_table_2 里面涉及到修改表 t3 的事務(wù)先執(zhí)行完成，就會從 hash_table_2 中把 db1.t3 這一項去掉。
5. 這樣 coordinator 會發(fā)現(xiàn)跟事務(wù) T 沖突的 worker 只有 worker_1 了，因此就把它分配給 worker_1。
6. coordinator 繼續(xù)讀下一個中轉(zhuǎn)日志，繼續(xù)分配事務(wù)。

也就是說，每個事務(wù)在分發(fā)的時候，跟所有 worker 的沖突關(guān)系包括以下三種情況：

1. 如果跟所有 worker 都不沖突，coordinator 線程就會把這個事務(wù)分配給最空閑的 woker;
2. 如果跟多于一個 worker 沖突，coordinator 線程就進入等待狀態(tài)，直到和這個事務(wù)存在沖突關(guān)系的 worker 只剩下 1 個；
3. 如果只跟一個 worker 沖突，coordinator 線程就會把這個事務(wù)分配給這個存在沖突關(guān)系的 worker。

這個按表分發(fā)的方案，在多個表負(fù)載均勻的場景里應(yīng)用效果很好。但是，如果碰到熱點表，比如所有的更新事務(wù)都會涉及到某一個表的時候，所有事務(wù)都會被分配到同一個 worker 中，就變成單線程復(fù)制了。

1.2 按行分發(fā)策略

要解決熱點表的并行復(fù)制問題，需要使用按行并行復(fù)制的方法。按行并行復(fù)制的核心思路就是：如果兩個事務(wù)沒有更新相同的行，在備庫上可以并行執(zhí)行，這時候就要求binlog的格式必須是row。這時候，我們判定事務(wù)T和worker沖突的規(guī)則是“修改同一行”。

按行復(fù)制和按表復(fù)制也是為每個worker分配一個hash表，只是按行復(fù)制時，在考慮主鍵的同時還要考慮唯一索引的沖突。

CREATE TABLE `t1` (
  `id` int(11) NOT NULL,
  `a` int(11) DEFAULT NULL,
  `b` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `a` (`a`)
) ENGINE=InnoDB;


insert into t1 values(1,1,1),(2,2,2),(3,3,3),(4,4,4),(5,5,5);

這兩個事務(wù)的主鍵不一致，但是如果分到不同worker，有可能出現(xiàn)sessionB先行，這時候id=1對應(yīng)的a值還是1，就會出現(xiàn)唯一鍵沖突的問題。因此，基于行的策略，需要考慮唯一鍵，即key為：“庫名+表名+索引a的名字+a的值”；

因此，上表例子中，表t1執(zhí)行sessionB語句，在binlog記錄了數(shù)據(jù)行修改前后各個字段的值，coordinator解析語句時，這個事務(wù)的hash表有三個項：

• key=hash_func(db1+t1+"PRIMARY"+2)，value=2；這里的value=2是因為修改前后的id值不變，出現(xiàn)了兩次；
• key=hash_func(db1+t1+"a"+2),value=1；表示會影響到表a=2的數(shù)據(jù)行；
• key=hash_func(db1+t1+"a"+1),value=1；表示會影響到表a=1的數(shù)據(jù)行；

相比于按表并行分發(fā)策略，按行并行策略在決定線程分發(fā)的時候：

• 需要消耗更多的計算資源；
• 要能夠從 binlog 里面解析出表名、主鍵值和唯一索引的值。也就是說，主庫的 binlog 格式必須是 row；
• 表必須有主鍵；
• 不能有外鍵。表上如果有外鍵，級聯(lián)更新的行不會記錄在 binlog 中，這樣沖突檢測就不準(zhǔn)確。

對比按表分發(fā)和按行分發(fā)這兩個方案的話，按行分發(fā)策略的并行度更高。不過，如果是要操作很多行的大事務(wù)的話，按行分發(fā)的策略有兩個問題：

• 耗費內(nèi)存。比如一個語句要刪除 100 萬行數(shù)據(jù)，這時候 hash 表就要記錄 100 萬個項。
• 耗費 CPU。解析 binlog，然后計算 hash 值，對于大事務(wù)，這個成本還是很高的。

所以，我在實現(xiàn)這個策略的時候會設(shè)置一個閾值，單個事務(wù)如果超過設(shè)置的行數(shù)閾值（比如，如果單個事務(wù)更新的行數(shù)超過 10 萬行），就暫時退化為單線程模式，退化過程的邏輯大概是這樣的：

• coordinator 暫時先 hold 住這個事務(wù)；
• 等待所有 worker 都執(zhí)行完成，變成空隊列；
• coordinator 直接執(zhí)行這個事務(wù)；
• 恢復(fù)并行模式。

2 各數(shù)據(jù)庫版本并行復(fù)制策略

2.1 MySQL5.6并行復(fù)制策略

5.6版本開始支持按庫并行復(fù)制的策略，由于是按庫，自然粒度比較粗。這個策略的并行效果，取決于壓力模型，如果主庫上有多個DB，并且各個DB的壓力均衡，這個策略還好：

• 構(gòu)建hash值只需要庫名，而且一個實例上的DB數(shù)不可能會很多，不會出現(xiàn)構(gòu)建100萬個項這種情況；
• 不要求binlog格式，因為statement格式的binlog也可以很容易拿到庫名。

但是問題也比較明顯，比如大促項目的數(shù)據(jù)庫和運營后臺的數(shù)據(jù)庫一定不是均衡的，因此，策略的應(yīng)用性有些差。

2.2 MariaDB并行復(fù)制策略

MariaDB是基于redo log的組提交（group commit）特性實現(xiàn)：

• 能夠在一個組內(nèi)提交的事務(wù)，一定不會修改同一行；原因在于說：事務(wù)在執(zhí)行數(shù)據(jù)更新或者DDL時一定會加鎖，只有事務(wù)提交后才會釋放鎖，所以，借助于鎖的互斥性，保證了事務(wù)的原子性；
• 主庫上可以并行執(zhí)行的事務(wù)，備庫上也一定是可以并行執(zhí)行的；

在實現(xiàn)上：

• 在一組里面一起提交的事務(wù)，有一個相同的commit_id，下一組就是commit_id+1；
• commit_id直接寫入binlog中；
• 傳到備庫應(yīng)用時，相同commit_id事務(wù)分發(fā)到多個worker執(zhí)行；
• 這一組全部執(zhí)行完成后，coordinator再去取下一批；

MariaDB的目標(biāo)就是“模擬主庫的并行執(zhí)行”，但是在具體實現(xiàn)上有些差距，畢竟主庫在一組事務(wù)commit時，下一組事務(wù)同時處于“執(zhí)行中”狀態(tài)。如圖所示：

圖片

MariaDB的執(zhí)行過程為：

圖片

在備庫上執(zhí)行的時候，要等第一組事務(wù)完全執(zhí)行完成后，第二組事務(wù)才能開始執(zhí)行，這樣系統(tǒng)的吞吐量就不夠。

另外，這個方案很容易被大事務(wù)拖后腿。假設(shè) trx2 是一個超大事務(wù)，那么在備庫應(yīng)用的時候，trx1 和 trx3 執(zhí)行完成后，就只能等 trx2 完全執(zhí)行完成，下一組才能開始執(zhí)行。這段時間，只有一個 worker 線程在工作，是對資源的浪費。

2.3 MySQL5.7版本并行復(fù)制策略

5.7版本提供了類似于MariaDB策略，并增加參數(shù)slave-parallel-type控制并行策略：

• 配置為 DATABASE，表示使用 MySQL 5.6 版本的按庫并行策略；
• 配置為 LOGICAL_CLOCK，表示的就是類似 MariaDB 的策略。不過，MySQL 5.7 這個策略，針對并行度做了優(yōu)化。

優(yōu)化點在于，把階段進行了提前，執(zhí)行中的事務(wù)可能會存在沖突，commit狀態(tài)的事務(wù)可能又有些延遲，MySQL5.7允許同時處于prepare狀態(tài)的事務(wù)執(zhí)行并行操作，因為已經(jīng)prepare狀態(tài)的事務(wù)一定也已經(jīng)通過鎖沖突的檢測：

• 同時處于prepare狀態(tài)的事務(wù)在備庫執(zhí)行時可以并行；
• 處于prepare狀態(tài)的事務(wù)與commit狀態(tài)的事務(wù)之間，可以并行；

binlog 的組提交的時候，介紹過兩個參數(shù)：

• binlog_group_commit_sync_delay 參數(shù)，表示延遲多少微秒后才調(diào)用 fsync;
• binlog_group_commit_sync_no_delay_count 參數(shù)，表示累積多少次以后才調(diào)用 fsync。

這兩個參數(shù)是用于故意拉長 binlog 從 write 到 fsync 的時間，以此減少 binlog 的寫盤次數(shù)。在 MySQL 5.7 的并行復(fù)制策略里，它們可以用來制造更多的“同時處于 prepare 階段的事務(wù)”。這樣就增加了備庫復(fù)制的并行度。

也就是說，這兩個參數(shù)，既可以“故意”讓主庫提交得慢些，又可以讓備庫執(zhí)行得快些。在 MySQL 5.7 處理備庫延遲的時候，可以考慮調(diào)整這兩個參數(shù)值，來達(dá)到提升備庫復(fù)制并發(fā)度的目的。

2.4 MySQL5.7.22版本的并行復(fù)制策略

MySQL 5.7.22 版本里，MySQL 增加了一個新的并行復(fù)制策略，基于 WRITESET 的并行復(fù)制，新增了一個參數(shù) binlog-transaction-dependency-tracking，用來控制是否啟用這個新策略。這個參數(shù)的可選值有以下三種。

• COMMIT_ORDER，根據(jù)同時進入 prepare 和 commit 來判斷是否可以并行的策略。
• WRITESET，表示的是對于事務(wù)涉及更新的每一行，計算出這一行的 hash 值，組成集合 writeset。如果兩個事務(wù)沒有操作相同的行，也就是說它們的 writeset 沒有交集，就可以并行。
• WRITESET_SESSION，是在 WRITESET 的基礎(chǔ)上多了一個約束，即在主庫上同一個線程先后執(zhí)行的兩個事務(wù)，在備庫執(zhí)行的時候，要保證相同的先后順序。

當(dāng)然為了唯一標(biāo)識，這個 hash 值是通過“庫名 + 表名 + 索引名 + 值”計算出來的。如果一個表上除了有主鍵索引外，還有其他唯一索引，那么對于每個唯一索引，insert 語句對應(yīng)的 writeset 就要多增加一個 hash 值。

這跟前面介紹的基于 MySQL 5.5 版本的按行分發(fā)的策略是差不多的。不過，MySQL 官方的這個實現(xiàn)還是有很大的優(yōu)勢：

• writeset 是在主庫生成后直接寫入到 binlog 里面的，這樣在備庫執(zhí)行的時候，不需要解析 binlog 內(nèi)容（event 里的行數(shù)據(jù)），節(jié)省了很多計算量；
• 不需要把整個事務(wù)的 binlog 都掃一遍才能決定分發(fā)到哪個 worker，更省內(nèi)存；
• 由于備庫的分發(fā)策略不依賴于 binlog 內(nèi)容，所以 binlog 是 statement 格式也是可以的。

因此，MySQL 5.7.22 的并行復(fù)制策略在通用性上還是有保證的。當(dāng)然，對于“表上沒主鍵”和“外鍵約束”的場景，WRITESET 策略也是沒法并行的，也會暫時退化為單線程模型。