认识达内从这里开始

高可用性架构开发是大多数程序员在开发软件的时候都需要满足的一个编程开发需求，而本文我们就通过案例分析来简单了解一下，高可用架构开发方法分享。

semi-sync半同步复制

MySQL有三种同步模式，分别是：

1、异步复制：MySQL中默认的复制是异步的，主库在执行完客户端提交的事务后会立即将结果返回给客户端，并不关心从库是否已经接收并且处理。存在问题就是，如果主库的日志没有及时同步到从库，然后主库宕机了，这时候执行故障转移，在从库冲选主，可能会存在选出的主库中数据不完整;

2、全同步复制：指当主库执行完一个事务，并且等到所有从库也执行完成这个事务的时候，主库在提交事务，并且返回数据给客户端。因为要等待所有从库都同步到主库中的数据才返回数据，所以能够保证主从数据的一致性，但是数据库的性能必然受到影响;

3、半同步复制：是介于全同步和全异步同步的一种，主库至少需要等待一个从库接收并写入到RelayLog文件即可，主库不需要等待所有从库给主库返回ACK。主库收到ACK，标识这个事务完成，返回数据给客户端。

MySQL中默认的复制是异步的，所以主库和从库的同步会存在一定的延迟，更重要的是异步复制还可能引起数据的丢失。全同步复制的性能又太差了，所以从MySQL5.5开始，MySQL以插件的形式支持semi-sync半同步复制。

半同步复制潜在的问题

在传统的半同步复制中，主库写数据到binlog，并且执行commit提交事务后，会一直等待一个从库的ACK。从库会在写入RelayLog后，将数据落盘，然后回复给主库ACK，主库收到这个ACK才能给客户端事务完成的确认。

这样会存在问题就是，主库已经将该事务的commit存储到了引擎层，应用已经可以看到数据的变化了，只是在等待从库的返回，如果此时主库宕机，可能从库还没有写入RelayLog，就会发生主从库数据不一致。

为了解决这个问题，MySQL5.7引入了增强半同步复制。主库写入数据到binlog后，就开始等待从库的应答ACK，直到至少一个从库写入RelayLog后，并将数据落盘，然后返回给主库ACK，通知主库可以进行commit操作，然后主库再将事务提交到事务引擎，应用此时才能看到数据的变化。

不过看下来增强半同步复制，在同步给从库之后，因为自己的数据还没有提交，然后宕机了，主库中也是会存在数据的丢失，不过应该想到的是，这时候主库宕机了，是会重新在从库中选主的，这样新选出的主库数据是没有发生丢失的。

MySQLGroupReplication

MySQLGroupReplication组复制，又称为MGR。是OracleMySQL于2016年12月发布MySQL5.7.17推出的一个全新高可用和高扩展的解决方案。

引入复制组主要是为了解决传统异步复制和半同步复制可能产生数据不一致的问题。

MGR由若干个节点共同组成一个复制组，一个事务的提交，必须经过组内大多数节点(N/2+1)决议并通过，才能得以提交。

当客户端发起一个更新事务时，该事务先在本地执行，执行完成之后就要发起对事务的提交操作。在还没有真正提交之前，需要将产生的复制写集广播出去，复制到其它成员。因为事务是通过原子广播发送的，所以组中的成员要么都接收事务，要么都不接收事务。如果组中的所有成员收到了该广播消息(事务)，那么他们会按照之前发送事务的相同顺序收到该广播消息。因此，所有组成员都以相同的顺序接收事务的写集，并为事务建立全局顺序。因此，所有组成员都以相同的顺序接收事务的写集，并为事务建立全局顺序。

在不同组成员并发执行的事务可能存在冲突。冲突是通过检查和比较两个不同并发事务的writeset来验证的，这个过程称为认证。在认证期间，冲突检测在行级别执行的：如果在不同组成员上执行的两个并发事务更新了同一行数据，则存在冲突。根据冲突认证检测机制判断，按照顺序，一次提交的会正常执行，二次提交的事务会在事务发起的原始组成员上执行回滚,，组中的其他成员对该事务执行删除。如果两个事务经常发生冲突，那么好将这两个事务放在同一个组成员中执行，这样它们在本地锁管理器的协调下将都有机会提交成功，而不至于因为处在两个不同的组成员中由于冲突认证而导致其中一个事务被频繁回滚。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!请读者仅作参考。更多内容请加抖音太原达内IT培训学习了解。