MySQL主從復(fù)制,讀寫分離是互聯(lián)網(wǎng)常見(jiàn)的數(shù)據(jù)庫(kù)架構(gòu),該架構(gòu)最令人詬病的地方就是,在數(shù)據(jù)量較大并發(fā)量較大的場(chǎng)景下,主從延時(shí)會(huì)比較嚴(yán)重。
為什么主從延時(shí)這么大?

答:MySQL使用單線程重放RelayLog。
應(yīng)該怎么優(yōu)化,縮短重放時(shí)間?
答:多線程并行重放RelayLog可以縮短時(shí)間。
多線程并行重放RelayLog有什么問(wèn)題?

答:需要考慮如何分割RelayLog,才能夠讓多個(gè)數(shù)據(jù)庫(kù)實(shí)例,多個(gè)線程并行重放RelayLog,不會(huì)出現(xiàn)不一致。
為什么會(huì)出現(xiàn)不一致?
答:如果RelayLog隨機(jī)的分配給不同的重放線程,假設(shè)RelayLog中有這樣三條串行的修改記錄:
update account set money=100 where uid=58;
update account set money=150 where uid=58;
update account set money=200 where uid=58;
如果單線程串行重放:能保證所有從庫(kù)與主庫(kù)的執(zhí)行序列一致。
畫外音:最后money都將為200。
如果多線程隨機(jī)分配重放:多重放線程并發(fā)執(zhí)行這3個(gè)語(yǔ)句,誰(shuí)最后執(zhí)行是不確定的,最終從庫(kù)數(shù)據(jù)可能與主庫(kù)不同。
畫外音:多個(gè)從庫(kù)可能money為100,150,200不確定。
如何分配,多個(gè)從庫(kù)多線程重放,也能得到一致的數(shù)據(jù)呢?
答:相同庫(kù)上的寫操作,用相同的線程來(lái)重放RelayLog;不同庫(kù)上的寫操作,可以并發(fā)用多個(gè)線程并發(fā)來(lái)重放RelayLog。

如何做到呢?
答:設(shè)計(jì)一個(gè)哈希算法,hash(db-name) % thread-num,庫(kù)名hash之后再模上線程數(shù),就能很輕易做到,同一個(gè)庫(kù)上的寫操作,被同一個(gè)重放線程串行執(zhí)行。
畫外音:不同庫(kù)上的重放,是并行的,就起到了加速做用。
這個(gè)方案有什么不足?
答:很多公司對(duì)MySQL的使用是“單庫(kù)多表”,如果是這樣的話,仍然只有一個(gè)庫(kù),還是不能提高RelayLog的重放速度。
啟示:將“單庫(kù)多表”的DB架構(gòu)模式升級(jí)為“多庫(kù)多表”的DB架構(gòu)模式。
畫外音:數(shù)據(jù)量大并發(fā)量大的互聯(lián)網(wǎng)業(yè)務(wù)場(chǎng)景,“多庫(kù)”模式還具備著其他很多優(yōu)勢(shì),例如:
(1)非常方便的實(shí)例擴(kuò)展:DBA很容易將不同的庫(kù)擴(kuò)展到不同的實(shí)例上;
(2)按照業(yè)務(wù)進(jìn)行庫(kù)隔離:業(yè)務(wù)解耦,進(jìn)行業(yè)務(wù)隔離,減少耦合與相互影響;
(3)非常方便微服務(wù)拆分:每個(gè)服務(wù)擁有自己的實(shí)例就方便了;
“單庫(kù)多表”的場(chǎng)景,多線程并行重放RelayLog還能怎么優(yōu)化?
答:即使只有一個(gè)庫(kù),事務(wù)在主庫(kù)上也是并發(fā)執(zhí)行的,既然在主庫(kù)上可以并行執(zhí)行,在從庫(kù)上也應(yīng)該能夠并行執(zhí)行呀?
新思路:將主庫(kù)上同時(shí)并行執(zhí)行的事務(wù),分為一組,編一個(gè)號(hào),這些事務(wù)在從庫(kù)上的回放可以并行執(zhí)行(事務(wù)在主庫(kù)上的執(zhí)行都進(jìn)入到prepare階段,說(shuō)明事務(wù)之間沒(méi)有沖突,否則就不可能提交),沒(méi)錯(cuò),MySQL正是這么做的。
解法:基于GTID的并行復(fù)制。
從MySQL5.7開(kāi)始,將組提交的信息存放在GTID中,使用mysqlbinlog工具,可以看到組提交內(nèi)部的信息:
20181014 23:52 server_id 58 XXX GTID last_committed=0 sequence_numer=1
20181014 23:52 server_id 58 XXX GTID last_committed=0 sequence_numer=2
20181014 23:52 server_id 58 XXX GTID last_committed=0 sequence_numer=3
20181014 23:52 server_id 58 XXX GTID last_committed=0 sequence_numer=4

和原來(lái)的日志相比,多了last_committed和sequence_number。
什么是last_committed?
答:它是事務(wù)提交時(shí),上次事務(wù)提交的編號(hào),如果具備相同的last_committed,說(shuō)明它們?cè)谝粋€(gè)組內(nèi),可以并發(fā)回放執(zhí)行。
總結(jié)
MySQL并行復(fù)制,縮短主從同步時(shí)延的方法,體現(xiàn)著這樣的一些架構(gòu)思想:
- 多線程是一種常見(jiàn)的縮短執(zhí)行時(shí)間的方法;
畫外音:例如,很多crontab可以用多線程,切分?jǐn)?shù)據(jù),并行執(zhí)行。
- 多線程并發(fā)分派任務(wù)時(shí),必須保證冪等性:MySQL提供了“按照庫(kù)冪等”,“按照commit_id冪等”兩種方式,很值得借鑒;
畫外音:例如,群消息,可以按照group_id冪等;用戶消息,可以按照user_id冪等。
具體到MySQL主從同步延時(shí):
- mysql5.5:不支持并行復(fù)制,大伙快升級(jí)MySQL版本;
- mysql5.6:按照庫(kù)并行復(fù)制,建議使用“多庫(kù)”架構(gòu);
- mysql5.7:按照GTID并行復(fù)制;
思路比結(jié)論重要,希望大家有收獲。
來(lái)源:架構(gòu)師之路
作者:沈劍
鏈接:https://mp.weixin.qq.com/s/pP2f7CYbT7ftM0tvk9c4mQ