全局事務認證模塊
全局事務認證模塊有一個消息隊列，用來存放收到的消息。這些消息主要是事務的Binlog Event，也有一部分狀態和控制消息。狀態表replication_group_member_stats中的字段COUNT_TRANSACTIONS_IN_QUEUE指的就是這個隊列中的事務數量。
全局事務認證模塊的核心任務是做衝突檢測，識別出那些同時修改了同樣數據的事務，並做出相應的處理。衝突檢測時需要的信息包括三點。
·主鍵信息。
·事務執行時數據庫的快照版本。
·執行事務的MySQL實例的UUID。
衝突檢測需要的信息
MGR的衝突檢測中以數據行爲單位，兩個事務是不是修改了同樣的數據，是通過事務所修改的主鍵值來判斷的。當發現兩個事務修改了同樣的數據後，如何來判斷這兩個事務是不是同時執行呢？這裏用到了數據庫快照版本。數據庫快照是數據庫的一個瞬時狀態，每個寫操作都會導致數據庫狀態的變化，不同的狀態用不同的快照版本來表示。快照版本是用GTID來表示的，每個寫事務都會產生一個唯一的GTID，這個GTID由全局事務認證模塊產生，且在事務提交時會被添加到全局變量gtid_executed中。因此，gtid_executed的內容就是MySQL數據庫的快照版本。
衝突檢測數據庫
全局事務認證模塊中還維護了一個衝突檢測數據庫，它是主鍵哈希+快照版本的列表。快照版本存儲的是最後一個修改此主鍵事務的快照版本加上這個事務的GTID。收到事務信息後，全局事務認證模塊會根據Transaction_context_log_event中的主鍵信息，從衝突檢測數據庫中檢索出所有主鍵的快照版本和該事務的快照版本進行對比。當前事務的快照版本必須要包含檢索出的所有主鍵快照版本中的GTID，否則就是有衝突。
衝突處理
衝突檢測完成後，全局認證模塊接下來的處理是有本地事務和異地事務區分的。Transaction_context_log_event中記錄了產生這個事務的MySQL實例的UUID。根據這個UUID，就能判斷出這是一個本地事務還是異地事務。對於本地事務處理如下。
·如果沒有衝突，喚醒這個事務的線程，並且告訴它完成提交操作。
·如果有衝突，喚醒這個事務的線程，並且告訴它發生衝突，需要回滾。
·不論是否有衝突，Binlog Event都會被丟棄。
對於異地事務的處理如下。
·如果沒有衝突，將這個事務的Binlog Event寫入Relay log中，讓group_replication_applier通道去執行。
·如果有衝突，則丟棄這個事務的Binlog Event。
衝突檢測數據庫的清理
隨着使用時間越來越長，衝突檢測數據庫中維護的主鍵信息會越來越多，會佔用大量內存。爲了減少內存的使用並提高查詢效率，全局事務認證模塊需要定期的清理衝突檢測數據庫。如果一個事務已經在所有成員上執行了，其它事務的執行肯定不會和它有衝突，因此這個事務的所有主鍵信息就可以從衝突檢測數據庫中移除。主鍵信息的清理是依據成員上的全局變量gtid_executed中的GTID集合來做的。全局認證模塊啓動了一個廣播線程，每60秒將自己的gtid_executed中的GTID集合廣播到所有成員上。全局認證模塊收到所有成員的GTID集合後，取它們的交集。這個交集中包含的就是那些已經在所有成員上執行了的事務GTID的集合，稱作全局完成的GTID集合（replication_group_member_stats表中的TRANSACTIONS_COMMITTED_ALL_MEMBERS顯示的就是全局完成的GTID集合。）。全局事務認證模塊會將衝突檢測數據庫所有主鍵的快照版本和全局完成的GTID集合進行對比，如果快照版本GTID集合是全局完成的GTID集合的子集，則這個主鍵的信息就會從衝突檢測數據庫中清除掉。
異地事務執行模塊
爲了執行異地事務的Binlog Event，MGR會自動創建一個名爲group_replication_applier的通道。這個通道的Receiver線程是關閉的，不會從其它成員上去複製Binlog Event。所有的Binlog Event都是由全局事務認證模塊通過API寫入Relay log的。
事務流程的總結
事務在MGR中的執行過程可以總結爲以下三個部分。
·網絡傳輸。
·事務在本地的執行過程。
·事務在異地的執行過程。
網絡傳輸
MGR通過Paxos協議來傳播事務信息。Paxos保障所有的事務信息按照同樣的順序傳播到所有成員上。
事務在本地成員上的執行過程
事務在本地提交時（prepare之後，寫Binlog之前），將事務信息發送至通信模塊，然後開始等待事務認證結果。通信模塊將事務排序後發送到本地成員的全局事務認證模塊。全局事務認證模塊做完衝突檢測後，喚醒該事務繼續執行，或回滾。
事務在異地成員上的執行過程
通訊模塊將事務排序後發送到全局事務認證模塊。全局事務認證模塊認證成功後，將該事務的Binlog Event寫入Relay log，由group_replication_applier通道來執行。如果全局事務認證模塊認證失敗，則會丟棄該事務的Binlog Event。