一、MySQL MGR演化
1.1 MySQL異步複製
master事務的提交不需要經過slave的確認，slave是否接收到master的binlog，master並不care。slave接收到master binlog後先寫relay log，最後異步地去執行relay log中的sql應用到自身。由於master的提交不需要確保slave relay log是否被正確接受，當slave接受master binlog失敗或者relay log應用失敗，master無法感知。
1.2 MySQL半同步複製
基於傳統異步存在的缺陷，mysql在5.5版本推出半同步複製。可以說半同步複製是傳統異步複製的改進，在master事務的commit之前，必須確保一個slave收到relay log並且響應給master以後，才能進行事務的commit。但是slave對於relay log的應用仍然是異步進行的，原理如下圖所示:
1.3 MySQL組複製（MGR）
MySQL是目前最流行的開源關係型數據庫，國內金融行業也開始全面使用，其中MySQL 5.7.17提出的MGR（MySQL Group Replication）既可以很好的保證數據一致性又可以自動切換，具備故障檢測功能、支持多節點寫入，MGR是一項被普遍看好的技術。
MGR （MySQL Group Replication）是MySQL自帶的一個插件，可以靈活部署。MySQL MGR集羣是多個MySQL Server節點共同組成的分佈式集羣，每個Server都有完整的副本，它是基於ROW格式的二進制日誌文件和GTID特性。架構主要是APIs層、組件層、複製協議模塊層和GCS API+Paxos引擎層構成。
應用發來的事務從MySQL Server經過MGR的APIs接口層分發到組件層，組件層去capture事務相關信息，然後經過複製協議層進行事務傳輸，最後經過GCS API+Paxos引擎層保證事務在各個節點數據最終一致性。這是事務進入MGR層內部處理過程。
MGR由若干個節點共同組成一個複製組，一個事務的提交，必須經過組內大多數節點（N / 2 + 1）決議並通過，才能得以提交。如上圖所示，由3個節點組成一個複製組，Consensus層爲一致性協議層，在事務提交過程中，發生組間通訊，由2個節點決議(certify)通過這個事務，事務才能夠最終得以提交併響應。
引入組複製，主要是爲了解決傳統異步複製和半同步複製可能產生數據不一致的問題。組複製依靠分佈式一致性協議(Paxos協議的變體)，實現了分佈式下數據的最終一致性，提供了真正的數據高可用方案(是否真正高可用還有待商榷)。其提供的多寫方案，給我們實現多活方案帶來了希望。
1.4 MySQL組複製的特性和限制
特性優點：
1、高一致性，基於原生複製及paxos協議的組複製技術，並以插件的方式提供，提供一致數據安全保證；
2、高容錯性，只要不是大多數節點壞掉就可以繼續工作，有自動檢測機制，當不同節點產生資源爭用衝突時，不會出現錯誤，按照先到者優先原則進行處理，並且內置了自動化腦裂防護機制；
3、高擴展性，節點的新增和移除都是自動的，新節點加入後，會自動從其他節點上同步狀態，直到新節點和其他節點保持一致，如果某節點被移除了，其他節點自動更新組信息，自動維護新的組信息；
4、高靈活性，有單主模式和多主模式，單主模式下，會自動選主，所有更新操作都在主上進行；多主模式下，所有server都可以同時處理更新操作。
限制：（具體可參考官方文檔說明：https://dev.mysql.com/doc/refman/5.7/en/group-replication-requirements-and-limitations.html）
1、僅支持InnoDB表，並且每張表一定要有一個主鍵，用於做write set的衝突檢測；
2、必須打開GTID特性，二進制日誌格式必須設置爲ROW，用於選主與write set；主從狀態信息存於表中（--master-info-repository=TABLE 、--relay-log-info-repository=TABLE），--log-slave-updates打開；
3、COMMIT可能會導致失敗，類似於快照事務隔離級別的失敗場景
4、目前一個MGR集羣最多支持9個節點
5、不支持外鍵於save point特性，無法做全局間的約束檢測與部分事務回滾
6、二進制日誌不支持binlog event checksum
二、MGR原理
2.1 MGR集羣中事務整個生命週期
接下來從全局角度看事務整個生命週期，DB1 、DB2 、DB3構成的MGR集羣， 集羣中每個DB都有MGR層，MGR層功能也可簡單理解爲由Paxos模塊和衝突檢測Certify模塊實現。Paxos模塊是基於Paxos算法確保所有節點收到相同廣播消息，transaction message就是廣播消息的內容結構；衝突檢測Certify模塊進行衝突檢測確保數據最終一致性，其中certification info是衝突檢測中內存結構；本文詳細介紹衝突檢測模塊實現原理，Paxos算法實現部分後續對比Raft算法詳細介紹。
當DB1上有事務T1要執行時，T1對DB1是來說本地事務，對於DB2、DB3來說是遠端事務；DB1上在事務T1在被執行後，會把執行事務T1信息廣播給集羣各個節點，包括DB1本身，通過Paxos模塊廣播給MGR集羣各個節點，半數以上的節點同意並且達成共識，之後共識信息進入各個節點的衝突檢測certify模塊，各個節點各自進行衝突檢測驗證，最終保證事務在集羣中最終一致性。
在衝突檢測通過之後，本地事務T1在DB1直接提交即可，否則直接回滾。遠端事務T1在DB2和DB3分別先更新到relay log，然後應用到binlog，完成數據的同步，否則直接放棄該事務。
2.2 transaction message和certification info
介紹衝突檢測實現原理之前，先介紹一下廣播信息transaction message、衝突檢測內存certification info的結構組成。
transaction message
如圖8所示，transaction message保存是事務T1要更新行的的相關信息,有transaction_context_log_event和gtid_log_event及log_event_group三部分組成。
具體組成：
1 write set 叫寫入集合，是事務更新行相關信息的Hash值。
write set=Hash（庫名+表名+主鍵（唯一鍵）字段信息）
2 gtid_executed爲已經執行過的事務gtid集合，也即事務快照版本。
3 把write set 和gtid_executed打包成爲事務上下文信息
transaction_context_log_event。
4 gtid_log_event爲已經執行過的事務gtid集合。
5 log_event_group爲事務日誌信息，後續要更新到relay log中。
6 把3和4和5一起打包成爲transaction message廣播給其它節點。
certification info
廣播的信息到達衝突檢測模塊certification之後是如何工作？
每個節點都有一個certification info的內存結構，certification info保存了通過沖突檢測的事務的write set和gtid_executed。certification info相當於一個map，key是string結構，保存write set中提取的主鍵值；value是set集合，保存gtid_executed事務快照版本；例如T1事務，T1更新數據庫d1中的表t1中兩行數據id=1和id=2，它對應快照版本UUID_MGR是:1-100，剛開始certification info爲空，所以直接提交，之後certification info中快照版本直接更新爲1-101.
2.3 衝突檢測核心機制！敲黑板！
通過上面的例子可知通過沖突檢測標準：若 transaction UUID_MGR ">="certification info UUID_MGR，則衝突檢測通過。
根據上述標準舉例，事務T2，更新id=2的行，事務T2的UUID_MGR爲1-102, 節點中衝突檢測模塊中的certification info中的UUID_MGR爲1-101,這裏T2:UUID_MGR:1-102>UUID_MGR:1-100，則T2衝突檢測通過。
反之，事務T3，更新id=1的行，事務T3的UUID_MGR爲1-100, 節點中衝突檢測模塊中的certification info中的UUID_MGR爲1-101，很明顯T3:UUID_MGR:1-100<UUID_MGR:1-101，則T3衝突檢測失敗，事務回滾或者丟棄。
上面是針對於單獨一個寫來進行判斷，現在我們來展示一下多節點模式中，多個事務同時寫入時衝突檢測機制。如下圖所示，三個事務T4、T5、T6並行寫入某個MySQL節點，通過了Paxos協議模塊達成一致性共識，進行衝突檢測時遵循下面三個原則：
1）多個事務修改同一個id對應的數值，需要按照先後順序進行衝突檢測。
2）多個事務同時對不同的id進行修改，各自進行修改即可。
3）不同的事務對同一個id修改，需要按照先後順序進行衝突檢測即。
事務T4和事務T5同時更新id=1的行，按照先來後到順序進行衝突檢測，T4先到先進行衝突檢測。
事務T4，更新id=1的行，事務T4的UUID_MGR爲1-102, 節點中衝突檢測模塊中的certification info中id=1的UUID_MGR爲1-101,很明顯T2:UUID_MGR:1-102>UUID_MGR:1-101,則T4衝突檢測通過,更新爲certification info中UUID_MGR爲1-103。
事務T5，更新id=1的行，事務T5的UUID_MGR爲1-100, 節點中衝突檢測模塊中的certification info中id=1的UUID_MGR爲1-102,其中T5:UUID_MGR:1-100>UUID_MGR:1-102,則T5衝突檢測不通過。
事務T6，更新id=3的行，事務T6的UUID_MGR爲1-100, 節點中衝突檢測模塊中的certification info中id=3的UUID_MGR爲空,其中T6:UUID_MGR:1-100>UUID_MGR,則T6衝突檢測通過,更新爲certification info中UUID_MGR爲1-101。
事務T4和事務T5並行修改id=1，T4寫入成功，T5丟棄，T6寫入id=3事務，寫入成功。
隨着 write set不斷寫入certification info中，內存消耗會相應增大，MGR有配套的write set 清理線程，每隔一段時間去清理已經在節點應用或者回放的事務的write set信息。
2.4 MGR特點
