爱站程序员基地该内容是作者在全球运维技术大会上分享主题中的部分内容。提供给想了解MGR的读者参考!
为了让解析mgr过程变得相对有条理，我们从跟踪一个事务在mgr的执行流程开始。首先从对执行sql的用户线程的解析开始：
在mgr节点中，用户线程的执行流程跟在普通mysql节点的执行流程，几乎是没有区别的。 唯一的区别就是，在事务的binlog提交阶段，增加了一个函数，这个函数的名称叫 group_replication_trans_before_commit, 这个函数作用就是将事务日志写入本地的通道， 然后就等待mgr将事务日志通过paxos协议进行全局扩散， 并利用事物日志进行事务间的冲突检查。当mgr完成冲突检查之后， 就会将用户线程唤醒。用户线程被唤醒以后呢，就会进行根据冲突检查的结果， 来决定继续提交这个事务还是回滚这个事务。 下面我们来看一下，在MGR内部，相关线程是怎么对事务来进行处理的。
前面讲到，用户（执行sql）线程将事务日志写入到本地通道之后， 后续对这个事务日志的处理，由MGR的线程来执行。 首先我们来看这个主任务线程xcom_taskmain2线程， 该线程的作用就是将本地通道的消息通过paxos协议进行全局(整个集群范围）一致性广播， 广播完毕之后， 就调用executed_msg函数执行消息（包含事务日志），但一个消息被执行的前提是： 这个消息的类型不是一个no_op类型的消息， 也就是广播成功的消息。 广播成功的消息，也就是被大多数节点所接受的消息。但是，在此步骤，executed_msg函数对消息的执行，并不是真正的执行，而是将消息丢到队列m_notification_queque里面。
接下来，如上面的图片所示，对这个消息的处理，由process_notification线程来完成的，也就是处理消息的线程。 而这个线程的作用， 类似一个消息中转站，将m_notification_queque队列里面的消息逐个取出，然后根据消息类型的不同，调用不同的函数进行处理。我们来看on_message_received 函数的具体代码：
将从m_notification_queue队列里面取出的消息，根据消息的类型，调用不同的函数进行处理。如果是一个事务类型的消息，也就是CT_TRANSACTION_MESSAGE类型的消息，则调用函数handle_transaction_message来进行处理。下面这个图就是该函数的处理过程。
该函数最终将消息丢入应用模块（applier_module）的队列里面， 队列的名称为incoming. 将包含事务日志的消息丢入该队列后， process_notification的线程的任务完成。
接下来的消息处理由applier线程来完成。流程如下图
applier线程通过调用函数applier_thread_handle函数来处理incoming队列的消息，处理过程见上面的流程图或者见下面的代码段：
该函数的第一行是获取incoming队列的头部第一个消息，然后根据消息/packet不同的类型，调用不同的函数来进行处理。如果是一个DATA_PACKET_TYPE类型的消息，则调用app_data_packet函数进行处理。 因为事务的binlog日志里面包含的是一行一行的记录，所以是一个数据类型的消息，因此会调用该函数处理。 而apply_data_packet函数，后面会调用冲突检测模块的函数，也就是
Certifier::certify函数验证冲突，验证从不同节点发起的事务之间是否有冲突（同一节点发起的事务肯定不冲突），验证冲突的方法接下来介绍。验证完毕之后，将调用releaseTicket函数来唤醒等待冲突验证结果的用户线程。用户线程被唤醒之后，根据冲突验证的结果来决定继续提交事务还是回滚事务。
这就是事务在MGR节点中的处理流程。 但事务跟事务之间是否冲突的部分，我们还没有详细介绍。下面我们将介绍这部分的内容：
在将事务冲突验证之前，先来看一下在mgr中，事务日志的内容。它包含两个部分，一部分是普通的mysql主从复制也会使用到的binlog，另外一部分就是专门为mgr所添加的，用来验证事务冲突的内容。它包含两个部分，第一个部分就是事务所涉及的主键，另外一个部分呢，就是事务执行时，当时该节点的数据版本，这个数据版本是用当时该节点已经执行过的所有事务的gtid集合来表示，也就是当时的gtid_executed的值，用来表示该节点当前已经执行那些事务，用这个值来表示事务执行时所基于的数据版本。利用这些内容呢，就能知道事务跟事务之间，它们是否对同一条记录进行操作，以及它们之间执行的先后顺序是否正确，由此此可以用这部分内容来检测事务跟事务之间是否有冲突。
左上角就是前面讲到的applier模块源代码中的incoming队列，里面包含待验证的事务消息。 将队列首部，包含事务日志的消息进行验证：将用于冲突检测的内容提出，得到事务所操作的记录的主键，以及事务执行时当时的数据快照版本。然后这些主键去write set 里面去查找，看是否命中。 如果没有命中，则该事务跟前面的事务不冲突，因为它们没有操作相同的记录，所以肯定不冲突。 如果命中，则比较数据版本。 如果是包含关系，则不冲突。 为什么说包含关系不冲突呢？ 如果是包含关系，则说明该事务是在前面的事务执行后的数据版本上执行的，它们之间有完全正常的先后顺序，所以是不冲突的。否则就是冲突的。
事务冲突验证完成之后，如果通过，则就会将用于冲突检测的内容往write set 里面丢。大家可能有个疑问，就是当事务的冲突验证完成之后，就会往write set 里面增加记录，因此可能会担心write set会越来越大。但是mgr后台有任务会及时去清理这个write set 里面不需要的记录。 哪里记录是可以被清理掉的呢？ 就是该记录所代表的事务已经在所有的节点都执行完，而且不跟已经进入队列里面的事务产生冲突，那么这些记录都是可以被删除的。 因为后续发起事务，它的数据版本都已经比执行完成的事务的数据版本大，它们是包含关系， 所以是绝对不冲突的，因此该记录也是失去了用于冲突检测的作用，可以被删除。
我们来看一下，具体的冲突检测的例子：
事务A,B,C，分别从A,B,C三个节点同时发起，且事务执行时的数据版本(节点之间没有数据延迟） 也一样， 但它们各自操作不同的记录，所以不冲突。
这个例子跟第一个例子的执行环境一样，唯一的区别就是事务A与事务B操作了同一条记录。 所以事务A与B产生了冲突。前面讲过，MGR中的paxos协议实现的就是消息的全局一致性广播，对并发的包含事务日志的消息进行全局统一的排序，事务A与事务B，虽然并发执行，但在全局还是有一个统一的排序。 假设事务A有幸排在前面，那么事务A在冲突检测时，前面还没有事务跟它冲突，冲突检测完成之后，将事务A用于冲突检测的内容丢入write set. 然后再进行事务B冲突检测的时候，在write set 集合里面去查找跟它相冲突的事务，就会发现事务A跟它冲突，因此事务B冲突检测失败，事务B接下来在innodb存储引擎中回滚。
第三个示列：三个事务貌似同时执行（但是否真正同时执行未知），但它们执行时基于的数据版本不一样。虽然事务A跟事务B操作了相同的记录，但是否冲突，取决于实际情况。如果事务真正执行的顺序是事务A 先执行，也就是事务A排序在前面，事务B在后面，那么它们之间是不冲突的，因为事务B的数据版本包含事务A的数据版本，它是在事务A提交完毕后的数据版本上执行的，它们的先后顺序完全正常。 假如是事务B先执行，事务A后执行，那么就会冲突。 大家可能有个疑问？为什么事务A后执行，它的数据版本反而小，这是因为A节点有延迟，有事务在其他节点已执行完成，但还没有在A节点relay完成，所以它即使后执行，但它的事务版本要低。
以上是事务在mgr中的执行流程，以及如何对它做事务冲突检测的。 分享出来，对大家在理解mgr的原理过程中提供参考。
