MySQL主從復(fù)制

MySQL主從復(fù)制有幾種模式

① 強同步（全同步），強同步的意思是主節(jié)點在接收到curd指令后，必須同步該指令到至少一個從節(jié)點，并且從節(jié)點需要收到binlog并且執(zhí)行relaylog成功后，才算事務(wù)提交完成

② 半同步，主節(jié)點收到curd操作指令后，從節(jié)點只需要收到日志就算事務(wù)完成了（這里收到日志的標(biāo)準(zhǔn)是從庫接受到binlog,并且成功寫入到relaylog），不需要等待從節(jié)點執(zhí)行日志內(nèi)容

半同步有兩種模式
1. AFTER_COMMIT：主庫將binlog傳遞給從庫的同時，也提交了事務(wù)，然后等待從庫返回ACK，然后返回結(jié)果給客戶端
2. AFTER_SYNC：主庫同步binlog給從庫，等待從庫返回寫入relaylog日志成功的ACK后再返回結(jié)果給客戶端
③ 異步，主節(jié)點接收操作后完成操作，立即響應(yīng)客戶端，同時異步復(fù)制數(shù)據(jù)給從節(jié)點

說明：對于從節(jié)點而言，收到binlog之后會先寫入relaylog（中轉(zhuǎn)日志）然后有專門的線程sql_thread讀取中轉(zhuǎn)日志解析并執(zhí)行的。

對于強同步和異步都比較極端，一個是性能堪憂一個是數(shù)據(jù)一致性比較弱，所以半同步是一個還不錯的折中方案

但是有幾個問題需要注意下

1. 對于模式AFTER_COMMIT模式而言，由于主庫先提交了事務(wù)，這就導(dǎo)致一個用戶兩次查詢可能導(dǎo)致不一樣的結(jié)果（即幻讀），比如第一次請求打在主庫上有數(shù)據(jù)，而第二次打在從庫上（或者因為主庫宕機發(fā)生主從切換），而從庫還沒來得及執(zhí)行relaylog同步數(shù)據(jù)，所以查不到

2. 對于AFTER_SYNC模式而言，如果你的系統(tǒng)監(jiān)聽了binlog做業(yè)務(wù)邏輯，等你的系統(tǒng)接收到binlog的時候，從庫還沒執(zhí)行完（因為IO競爭激烈等原因），這個時候你如果去查主庫，那你是查不到的，造成了數(shù)據(jù)不一致

對于模式AFTER_SYNC模式而言，我們可以根據(jù)業(yè)務(wù)的具體情況選擇

① 重試 

② 延遲隊列 

③ 不依賴binlog使用MQ等方法避免此類問題