一、緣起

mysql主從復(fù)制，讀寫分離是互聯(lián)網(wǎng)用的非常多的mysql架構(gòu)，主從復(fù)制最令人詬病的地方就是，在數(shù)據(jù)量較大并發(fā)量較大的場景下，主從延時會比較嚴重。

為什么mysql主從延時這么大？

回答：從庫使用【單線程】重放relaylog。

優(yōu)化思路是什么？

回答：使用單線程重放relaylog使得同步時間會比較久，導(dǎo)致主從延時很長，優(yōu)化思路不難想到，可以【多線程并行】重放relaylog來縮短同步時間。

mysql如何“多線程并行”來重放relaylog，是本文要分享的主要內(nèi)容。

二、如何多線程并行重放relaylog

通過多個線程來并行重放relaylog是一個很好縮短同步時間的思路，但實施之前要解決這樣一個問題：

如何來分割relaylog，才能夠讓多個work-thread并行操作數(shù)據(jù)data時，使得data保證一致性？

首先，【隨機的分配relaylog肯定是不行的】，假設(shè)relaylog中有這樣三條串行的修改記錄：

update account set money=100 where uid=58;

update account set money=150where uid=58;

update account set money=200where uid=58;

串行執(zhí)行：肯定能保證與主庫的執(zhí)行序列一致，最后得到money=200

隨機分配并行執(zhí)行：3個工作線程并發(fā)執(zhí)行這3個語句，誰最后執(zhí)行成功是不確定的，故得到的數(shù)據(jù)可能與主庫不同

好，對于這個問題，可以用什么樣的思路來解決呢（大伙怎么想，mysql團隊其實也就是這么想的）

【方法一：相同庫上的寫操作，用相同的work-thread來重放relaylog；不同庫上的寫操作，可以用多個work-thread并發(fā)來重放relaylog】

如何做到呢？

回答：不難，hash(db-name) % thread-num，庫名hash之后再模上線程數(shù)，就能夠做到。

存在的不足？

很多公司對mysql的使用是“單庫多表”，如果是這樣的話，仍然是同一個work-thread在串行執(zhí)行，還是不能提高relaylog的重放速度。

優(yōu)化方案：將“單庫多表”的模式升級為“多庫多表”的模式。

其實，數(shù)據(jù)量大并發(fā)量大的互聯(lián)網(wǎng)業(yè)務(wù)場景，“多庫”模式還具備著其他很多優(yōu)勢，例如：

（1）非常方便的實例擴展：dba很容易將不同的庫擴展到不同的實例上

（2）按照業(yè)務(wù)進行庫隔離：業(yè)務(wù)解耦，進行業(yè)務(wù)隔離，減少耦合與相互影響

（3）…

對于架構(gòu)師進行架構(gòu)設(shè)計的啟示是：使用多庫的方式設(shè)計db架構(gòu)，能夠降低主從同步的延時。

新的想法：“單庫多表”的場景，還有并行執(zhí)行優(yōu)化余地么？

仔細回顧和思考，即使只有一個庫，數(shù)據(jù)的修改和事務(wù)的執(zhí)行在主庫上也是并行操作的，既然在主庫上可以并行操作，在從庫上為啥就不能并行操作，而要按照庫來串行執(zhí)行呢（表示不服）？

新的思路：將主庫上同時并行執(zhí)行的事務(wù)，分為一組，編一個號，這些事務(wù)在從庫上的回放可以并行執(zhí)行（事務(wù)在主庫上的執(zhí)行都進入到prepare階段，說明事務(wù)之間沒有沖突，否則就不可能提交），沒錯，mysql正是這么做的。

【方法二：基于GTID的并行復(fù)制】

新版的mysql，將組提交的信息存放在GTID中，使用mysqlbinlog工具，可以看到組提交內(nèi)部的信息：

20160607 23:22 server_id 58 XXX GTID last_committed=0 sequence_numer=1

2016060723:22 server_id 58 XXX GTID last_committed=0 sequence_numer=2

2016060723:22 server_id 58 XXX GTID last_committed=0 sequence_numer=3

2016060723:22 server_id 58 XXX GTID last_committed=0 sequence_numer=4

和原來的日志相比，多了last_committed和sequence_number。

last_committed表示事務(wù)提交時，上次事務(wù)提交的編號，如果具備相同的last_committed，說明它們在一個組內(nèi)，可以并發(fā)回放執(zhí)行。

三、結(jié)尾

從mysql并行復(fù)制縮短主從同步時延的思想可以看到，架構(gòu)的思路是相同的：

（1）多線程是一種常見的縮短執(zhí)行時間的方法

（2）多線程并發(fā)分派任務(wù)時必須保證冪等性：mysql的演進思路，提供了“按照庫冪等”，“按照commit_id冪等”兩種方式，思路大伙可以借鑒

另，mysql在并行復(fù)制上的逐步優(yōu)化演進：

mysql5.5->不支持并行復(fù)制，對大伙的啟示：升級mysql吧

mysql5.6->按照庫并行復(fù)制，對大伙的啟示：使用“多庫”架構(gòu)吧

mysql5.7->按照GTID并行復(fù)制

我不是mysql的開發(fā)人員，也不是專業(yè)的dba，本文僅為一個思路的分享，希望大伙有收獲，如果不對也歡迎隨時指出。

大家可以點擊加入群：283943715java高級交流群里面有Java高級大牛直播講解知識點 走的就是高端路線（如果你想跳槽換工作 但是技術(shù)又不夠 或者工作上遇到了瓶頸 我這里有一個JAVA的免費直播課程 講的是高端的知識點基礎(chǔ)不好的誤入喲 只要你有1-5年的開發(fā)經(jīng)驗可以加群找我要課堂鏈接 注意：是免費的 沒有開發(fā)經(jīng)驗誤入哦）