你听说过MySQLMGR技术吗？MySQL是目前最流行的开源关系型数据库，在国内金融行业也得到了充分的应用。其中MySQL5.7.17提出的MGR（MySQLGroupReplication）既能保证数据一致性又能自动切换，并且具有故障检测功能，支持多节点写入，MGR是普遍看好的技术。本文介绍了MySQLMGR技术的演进过程、事务生命周期和事务冲突检测机制。首先介绍一下MGR技术的演进。传统的MySQL主从复制架构是MySQL维护数据一致性最基本的架构。如下图1所示，一主一从架构。dump线程将binlog日志文件推送到从库，从库的I/O线程将接收到的数据更新到relaylog，然后从库的SQL线程将relaylog作为binlog日志，直到主库和从库的binlog日志文件在数据上完全一致，实现了主从同步。图1主从复制示意图接下来我们来看一下MySQL的异步复制，如下图2所示，一个主从架构，应用程序发送的事务请求执行后写入binlog，主库master推送binlog日志到从库对于salve1和slave2库，主库不需要等待从库是否成功更新数据到relaylog，主库直接提交事务即可。这种模式牺牲了数据的一致性，不能保证主从数据的一致性。图2异步复制示意图模拟一个异步复制场景的例子，如下图3，三个人在说话，一个人在不停地讲话。不需要知道两个观众是否理解，也不需要观众回应。等到演讲结束，有可能听众没听懂，最后大家才意识到信息可能不一致。为了解决以上问题，MySQL5.5.8有了半同步复制。图3异步复制场景模拟图接下来我们看一下MySQL的半同步复制，如下图4，一主两从架构，应用发送的事务请求写入binlog后master库执行，master库将写入的binlog日志推送到slave1和slave2。半同步主库需要等待任意一个slave成功更新数据到relaylog，并在主库提交事务前通知主库。这确保至少有一个从站同步了数据。缩短延迟时间，保证数据安全。图4半同步仿真示意图一个半同步复制场景的例子，如下图5所示，三个人在说话，一个人不停地演讲。如果任何听众回应并理解，演讲者将继续演讲，否则演讲将停止。最后，当演讲结束时，至少有一位听众能够理解演讲者的意思，保证信息传递的连贯性。这种复制模式也有两个问题：MySQL不能自动切换，需要外力切库，运维复杂。过大的库Slave读压力会导致replicationdelay不断增加。MySQL5.7的MGR技术可以解决以上问题。图5半同步复制场景模拟至此，MGR技术诞生！MGR（MySQLGroupReplication）是MySQL自带的插件，可以灵活部署。MySQLMGR集群是由多个MySQLServer节点组成的分布式集群。每个Server都有一份完整的副本，它是基于ROW格式和GTID特性的二进制日志文件。MGR架构图如下图6所示，主要由APIs层、组件层、复制协议模块层和GCSAPI+Paxos引擎层组成。如图6所示，应用程序发送的事务通过MGR的APIs接口层从MySQLServer分发到组件层。组件层捕获交易相关信息，然后通过复制协议层传输交易，最后通过GCSAPI+Paxos引擎层。保证各节点交易数据的最终一致性。这是事务进入MGR层的内部处理过程。MGR集群中事务的整个生命周期是什么？接下来，从全局的角度来看一笔交易的整个生命周期。如下图7所示，由DB1、DB2、DB3组成的MGR集群，集群中的每个DB都有一个MGR层。MGR层的功能也可以简单理解为Paxos模块和冲突检测Certify模块的实现。Paxos模块是基于Paxos算法保证所有节点接收到相同的广播消息，交易消息就是广播消息的内容结构；冲突检测Certify模块进行冲突检测，保证数据的最终一致性，认证信息是冲突检测中的内存结构；本文详细介绍了冲突检测模块的实现原理，Paxos算法的实现将在后续与Raft算法的对比中详细介绍。当DB1上有事务T1要执行时，T1对DB1来说是本地事务，对DB2和DB3来说是远程事务；事务T1在DB1上执行后，会将执行事务T1的信息广播给各个集群节点，包括DB1本身，通过Paxos模块广播给MGR集群的各个节点，超过半数节点同意，达成共识.之后，共识信息进入各节点的冲突检测验证模块，各节点进行冲突检测和验证，最终确保交易在集群中。在最终一致性。冲突检测通过后，可以直接在DB1中提交本地事务T1，否则直接回滚。远程事务T1先分别更新到DB2和DB3中的relaylog，再应用到binlog完成数据同步，否则直接丢弃该事务。图7MGR组复制技术示意图上一节我们从全局的角度介绍了一个事务在MGR集群中从头到尾的整个处理过程，然后介绍了冲突检测机制的实现机制局部视角的细节。什么是交易信息和认证信息？在介绍冲突检测的实现原理之前，先介绍一下广播信息事务消息和冲突检测内存认证信息的结构。1事务消息如图8所示，事务消息存储了事务T1要更新的行的相关信息，由三部分组成：transaction_context_log_event、gtid_log_event、log_event_group。具体构成：writeset称为writeset，是交易更新行相关信息的Hash值。writeset=Hash(库名+表名+主键(唯一键)字段信息)gtid_executed为已经执行的事务gtid集合，即事务快照版本。将writeset和gtid_executed打包成事务上下文信息transaction_context_log_event。gtid_log_event是已经执行过的事务gtid集合。log_event_group是事务日志信息，后面会更新到relaylog中。将3、4、5一起打包成交易消息，广播给其他节点。图8广播信息内容结构2广播信息到达冲突检测模块认证后，认证信息如何工作？每个节点都有一个certificationinfo的内存结构，存储通过冲突检测的事务的writeset和gtid_executed。认证信息相当于一个map，key为字符串结构，保存writeset中提取的主键值；value是一个set集合，保存了gtid_executed事务的快照版本；例如T1事务，T1更新数据库d1中表t1的两行数据id=1，id=2，对应快照版本UUID_MGR为：1-100，一开始认证信息为空，所以直接提交，然后认证信息中的快照版本直接更新为1-101。图9Certificationinfo结构图冲突检测核心机制！敲黑板！从上面的例子可以看出，冲突检测标准是通过的：如果transactionUUID_MGR">="certificationinfoUUID_MGR，那么冲突检测是通过的。反之，事务T3更新了id=1的行，事务T3的UUID_MGR为1-100，节点中冲突检测模块的认证信息中的UUID_MGR为1-101。很明显T3:UUID_MGR:1-100
