一金刁、背景介紹

Mysql作為 DB持久化層的組件，一般采用的是的架構(gòu)模式级乐，在分布式疙咸，高可用的微服務(wù)背景下，那么是如何實(shí)現(xiàn)數(shù)據(jù)同步的一致性风科？

高可用主從架構(gòu)

Mysql有三種主從復(fù)制同步方式：

1. 全同步復(fù)制模式（組復(fù)制 MGR）
2. 異步復(fù)制模式
3. 半同步復(fù)制模式（version>5.5)撒轮。

值得注意的是，贼穆，目前我司用的是半同步復(fù)制模式题山，下面來看看幾種主從復(fù)制同步方式的不同之處。

二故痊、異步復(fù)制模式

MySQL異步復(fù)制是主從復(fù)制過程中默認(rèn)的復(fù)制模式顶瞳。主從復(fù)制涉及三個(gè)線程，master I/O線程、slave I/O線程慨菱、slave sql線程焰络。因?yàn)槭钱惒綇?fù)制，所以master事務(wù)的提交符喝，不需要經(jīng)過slave的確認(rèn)闪彼，即master I/O線程提交事務(wù)后，不需要等待slave I/O線程的回復(fù)確認(rèn)协饲，master并不保證binlog一定寫入到了relay log中畏腕；而slave I/O把binlog寫入relay log后，由slave sql線程異步執(zhí)行應(yīng)用到slave mysql中茉稠，slave I/O也不需要slave sql的回復(fù)確認(rèn)描馅，并不保證relay log日志完整寫入到了mysql中。

異步復(fù)制模式

三战惊、半同步復(fù)制模式

在異步復(fù)制和全同步復(fù)制之間流昏，主庫在執(zhí)行完客戶端提交的事務(wù)后不是立刻返回給客戶端扎即，而是等待至少一個(gè)從庫接收到并寫到 relay log 中才返回成功信息給客戶端（只能保證主庫的 Binlog 至少傳輸?shù)搅艘粋€(gè)從節(jié)點(diǎn)上）吞获，否則需要等待直到超時(shí)時(shí)間然后切換成異步模式再提交。

相對(duì)于異步復(fù)制谚鄙，半同步復(fù)制提高了數(shù)據(jù)的安全性各拷，一定程度的保證了數(shù)據(jù)能成功備份到從庫，同時(shí)它也造成了一定程度的延遲闷营，但是比全同步模式延遲要低烤黍，這個(gè)延遲最少是一個(gè) TCP/IP 往返的時(shí)間。所以傻盟，半同步復(fù)制最好在低延時(shí)的網(wǎng)絡(luò)中使用速蕊。

半同步模式不是 MySQL 內(nèi)置的，從 MySQL 5.5 開始集成娘赴，需要 master 和 slave 安裝插件開啟半同步模式规哲，如圖Master節(jié)點(diǎn)接收到客戶端的細(xì)節(jié)Commit部分。

半同步復(fù)制模式

但是存在一個(gè)問題：若主庫的事務(wù)已經(jīng)提交了诽表，但是等到從庫 ack的消息時(shí)唉锌，主庫宕機(jī)了，那么將無法返回給客戶端提交的信息竿奏。

image.png

此時(shí)袄简，可能的情況有兩種：

事務(wù)還沒發(fā)送到從庫上

此時(shí)，客戶端會(huì)收到事務(wù)提交失敗的信息泛啸，客戶端會(huì)重新提交該事務(wù)到新的主上绿语，當(dāng)宕機(jī)的主庫重新啟動(dòng)后，以從庫的身份重新加入到該主從結(jié)構(gòu)中，會(huì)發(fā)現(xiàn)吕粹，該事務(wù)在從庫中被提交了兩次伍纫，一次是之前作為主的時(shí)候，一次是被新主同步過來的昂芜。

事務(wù)已經(jīng)發(fā)送到從庫上

此時(shí)莹规，從庫已經(jīng)收到并應(yīng)用了該事務(wù)，但是客戶端仍然會(huì)收到事務(wù)提交失敗的信息泌神，重新提交該事務(wù)到新的主上良漱。

針對(duì)上述潛在問題，Mysql5.7引入了一種新的半同步方案：Loss-Less半同步復(fù)制如下圖調(diào)整了Commit與Watting Slave dump的位置欢际。

image.png

四母市、全同步復(fù)制模式

指當(dāng)主庫執(zhí)行完一個(gè)事務(wù)，然后所有的從庫都復(fù)制了該事務(wù)并成功執(zhí)行完才返回成功信息給客戶端损趋。因?yàn)樾枰却袕膸靾?zhí)行完該事務(wù)才能返回成功信息患久，所以全同步復(fù)制的模式的Mysql性能必然會(huì)受到嚴(yán)重的影響。

全復(fù)制模式流程

MySQL官方在5.7.17版本正式推出組復(fù)制（MySQL Group Replication浑槽，簡(jiǎn)稱MGR）

由若干個(gè)節(jié)點(diǎn)共同組成一個(gè)復(fù)制組蒋失，篙挽。如下圖所示，由3個(gè)節(jié)點(diǎn)組成一個(gè)復(fù)制組镊靴，Consensus層為一致性協(xié)議層铣卡，在事務(wù)提交過程中，發(fā)生組間通訊偏竟，由2個(gè)節(jié)點(diǎn)決議(certify)通過這個(gè)事務(wù)煮落，事務(wù)才能夠最終得以提交并響應(yīng)。

引入組復(fù)制踊谋，主要是為了解決傳統(tǒng)異步復(fù)制和半同步復(fù)制可能產(chǎn)生數(shù)據(jù)不一致的問題蝉仇。組復(fù)制依靠分布式一致性協(xié)議(Paxos協(xié)議的變體)，實(shí)現(xiàn)了分布式下數(shù)據(jù)的最終一致性褪子，提供了真正的數(shù)據(jù)高可用方案(是否真正高可用還有待商榷)量淌。其提供的多寫方案，給我們實(shí)現(xiàn)多活方案帶來了希望嫌褪。

基于傳統(tǒng)異步復(fù)制和半同步復(fù)制的呀枢。

琅拌。

MGR模式