在談MySQL5.7的數(shù)據(jù)強一致性之前先來看看5.5，5.6，5.7版本做數(shù)據(jù)半同步復(fù)制時的原理。
1.半同步復(fù)制(5.5、5.6)
過程分析：
1. session發(fā)起commit請求
2. flush binlog and fsync binlog
3. InnoDB引擎層commit
4. 發(fā)送binlog日志到slave，等待slave發(fā)送回ack確認
5. slave 接收binlog寫入realy log,刷盤完成發(fā)送ack確認包給master
6. master返回ok 信息給session
這種模式可能會遇到某些特殊情況導(dǎo)致數(shù)據(jù)不一致:
master在等待事務(wù)A返回ACK的時候宕機，此時新事務(wù)B在master宕機前開啟。導(dǎo)致的結(jié)果可能有2種情況：
(1). 當binlog未發(fā)送到從庫時：
事務(wù)B獲取到事務(wù)A提交的內(nèi)容，此時宕機故障切換到slave，事務(wù)B連同事務(wù)B獲取到的內(nèi)容都會丟失。事務(wù)A commit也沒有收到返回信息。
(2). binlog已經(jīng)發(fā)送給slave
事務(wù)B獲取到事務(wù)A提交的內(nèi)容，故障切換到salve ，B仍然獲取到A提交的內(nèi)容，沒毛病。事務(wù)A commit沒有收到反饋信息，若重新執(zhí)行該事務(wù)，則相當于執(zhí)行兩次A事務(wù).
2. 增強半同步復(fù)制(5.7)
由該參數(shù) rpl_semi_sync_master_wait_point=AFTER_SYNC/AFTER_COMMIT 兩個值選擇是否啟用增強半同步
當半同步模式為 AFTER_COMMIT 時，為上面分析的情況
當半同步模式為 AFTER_SYNC 模式時，則如下：
過程分析：
1. session發(fā)出commit請求
2. flush binlog and fsync binlog
3. 發(fā)送binlog到slave，等待slave發(fā)送ack確認信息
4. slave接收binlog，寫入realy log，刷盤完成發(fā)送ack確認包到master
5. InnoDB引擎層commit
6. master返回commit ok信息給session
此種情況下，當事務(wù)A在等待slave的ack時宕機，此時新事務(wù)B在master宕機前開啟。
(1). 事務(wù)B讀取不到事務(wù)A的內(nèi)容，因為事務(wù)A的engine層還沒有提交。這就是無損復(fù)制。
這里面有一個問題，當從庫準備返回給master ACK確認包時宕機了，也就是返回ACK給master沒成功，那么會發(fā)生什么呢？嘿嘿，下面一節(jié)會講到。
3. 半同步復(fù)制增加 ACK線程
mysql5.5 mysql5.6
(1). master dump thread 發(fā)送binlog events 給 slave 的IO thread，等待 slave 的ack回包
(2). slave 接受binlog events 寫入redo log ，返回 ack 包給master dump thread
(3). master dump thread 收到ack包 ，給session返回commit ok，然后繼續(xù)發(fā)送寫一個事務(wù)的binlog。
mysql5.7 新增ack線程
(1). master dump thread 發(fā)送binlog events 給 slave 的IO thread，開啟ack線程等待 slave 的ack回包，dump 線程繼續(xù)向slaveIO thread發(fā)送下一個事務(wù)的binlog。
(2). slave 接受binlog events 寫入redo log ，返回 ack 包給master ack線程，然后給session返回commit ok。
可以看到，mysql5.7半同步復(fù)制中增加了一個 ACK線程專門用來進行semi 復(fù)制的ACK確認，這提高了復(fù)制的tps。
