MGR中group_replication插件最重要的功能就是事務分發器的功能，這裏其分發的是Binlog Event，事務分發器的處理是在事務執行即將結束的時候。MGR將這稱作樂觀的事務執行策略，可以帶來更好的性能。但這種策略下，多個成員上的事務可能發生衝突。MGR需要一個衝突檢測機制來發現並處理衝突。根據事務處理過程中的不同處理步驟，MGR中事務分發器的功能劃分爲以下四個部分。
·本地事務控制模塊
·成員間的通信模塊
·全局事務認證模塊
·異地事務執行模塊
先來看下本地事務控制模塊，MySQL通過API向插件提供了事務執行過程中幾個重要階段的Hook接口，MGR通過這些接口來監控和控制事務的執行。MySQL的事務在提交時，內部會分成三個階段：準備（prepare）階段，記錄binlog文件階段和提交（commit）階段。MGR對本地事務的控制邏輯在before_commit這個接口中執行。before_commit是在事務的prepare階段之後，寫binlog文件階段之前被執行的。對本地事務的控制包括以下三個步驟。
1.發送事務信息
MGR首先將事務執行相關的信息打包，通過通信模塊的接口發送給本地的通信模塊，只要本地的通信模塊接收到了消息就返回成功（發送到其它成員是成員間通信模塊的職責）。事務信息包括主鍵信息、數據庫快照版本和事務產生的Binlog Event。
·主鍵信息是Server層生成Binlog Event的時候一同生成的。主鍵信息中記錄的並不是主鍵字段的值，而是字段值加上庫名、表名等哈希值。
·數據庫快照版本是當前MySQL的全局變量gtid_executed的值。它包含了當前事務提交時所有已經執行了的事務的GTID，代表了當前事務執行時數據庫的狀態。
·當發送事務信息時，Binlog Event還沒寫入Binlog文件。因此，Binlog Event是從當前線程的Binlog Cache中獲取的，而不依賴Binlog文件。
·Transaction_context_log_event，本地成員的UUID、主鍵信息和數據庫快照版本會被封裝進Transaction_context_log_event中，和事務產生的Binlog Event一起發出去。Transaction_context_log_event放在其它Binlog Event的前面。
2.等待全局事務認證模塊的認證結果
在事務信息發送成功後，事務會被阻塞，開始等待全局事務認證模塊的認證結果。事務認證完成後，全局事務認證模塊會喚醒當前事務的線程，讓事務繼續執行。
3.認證結果的處理
事務繼續執行後，會檢測認證結果。如果認證成功了，就繼續提交事務。如果認證失敗了，就會返回錯誤。然後由MySQL來執行Rollback的邏輯。