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的逻辑。
