关于MySQL Group Replication

前两天，听了公司DBA老大的分享，也是首次接触到了MGR这个架构，其对MGR的大力推崇，让做为业务开发人员的我也对其产生了兴趣，至此，用同事“老司机”的话说，是时候学习一波了。

1、CAP与MySQL

谈MGR以前，先要熟悉一下CAP与MySQL的关系。当前MySQL的master-slave架构，取AP舍C，嗯嗯，DBA们的PPT就是这样告诉俺们的。

C：（consistency）一致性，以前在同事分享时，你们一块儿讨论过什么叫一致性，后来能让你们比较认同的解释是：“违背了预约的一致性约束，就是违背了一致性”，这话看起来跟没说似的，可是其强调了一个很重要的点，即“约束条件”。例如，一张表的某个字段在现实世界中是惟一unique的，只是在建表的时候没指定unique key，而后某一天出了故障，插入了两条相同字段的record，这种状况，也应该算是违背了一致性的。只是通常在分布式系统的背景下，你们默认的理解都将其限定在不一样节点的value是否一致这个更窄的概念上，以方便讨论。

A：（availability）可用性，指全部的读写请求，在有限的时间内都能得到响应。我理解的A，应该是指一个request到达server以后，server可以在有限的时间内，发出一个response。不能把client-server当作整个系统，client发出的一个request根本就没到达server，天然不会有response。你把人家机房的光缆挖断了，而后挑战人家系统的可用性，这就蛋疼了。换个例子，好比server的CPU飙到最高了，这时候来一个request，server直接不处理，给丢了，这才是系统可用性应该考虑的范畴。

P：（partition-tolerance）分区容忍性，这个一直是个很容易让人困惑的概念，我比较认同的一个解释是：“在网络分区的状况下，被分隔的节点仍能正常对外服务”。就是说，因为网络的因素，将本来联通的分布式系统，分隔成彼此没法通讯的一个个子集了，这时候这个单独的子集可以继续对外提供服务。

我的理解：

1. 对于CAP别较真，网上一搜，众说纷纭，去扣CAP的概念、证实(至于那个反证的证实，着实蛋疼)都没意义，还容易疯。就是一个在设计系统的时候的参考，核心指导做用是说在设计的时候，别去追求完美，实事求是，具体问题具体分析，get这一点就足以了。

2. 在CAP中，没有舍谁取谁的，都是权衡罢了。这世间之事吧，就历来没有非此即彼。

接下来就以CAP的角度说说MySQL的master-slave架构：

所谓master-slave架构，就是由master负责写，slave负责读，而后将master的binlog不断的发送到slave执行，使整个DB集群达到一致。先来讲P，master与slave节点失联以后，木有关系，master仍是负责client发过来的写请求，slave仍是负责读请求，你们各司其职，也就实现了P，同时，因为master的数据没法同步给slave了，也就天然没法保证C了。还有就是哪怕在网络很是健康的状况，master与slave存在的延迟，也使整个集集群没法实现强一致。既然存在问题，也就必然存在着问题的解决之道，接下来就来讲说MGR。

2、MySQL group replication

在默认状况下，MySQL的复制（replication）策略是异步（asynchronous）复制，以下图：

图有点毛病，通常是在事务commit以后，才将binlog发送到slave，但问题是同样的，就是C太弱了，master将binlog发送出去以后，就无论了。要是slave没收到，那系统天然就不一致了，既然C太弱了，就能够想办法来保障C，好比采起半同步（semi-synchronous）的策略：

也即master等每个slave ACK以后，再提交事务，告诉client此次的更新成功了。如此，就保证commit以后，slave确定收到binlog了，天然也就提高了C。但问题也就随之而来了，即性能降低了，每一条变动SQL的性能降低带动系统QPS的降低，从而影响了A。此外，当集群中新增节点时，会让系统性能降低。看，问题又来了，那何如平衡C与A呢？MGR就提供了一个解决思路，先看看引入MGR以后，系统大概变成了什么样子：

如图，一个明显的变化就是系统再也不区分master与slave了，每一个节点都是master，均可以进行写，而后使用一致性算法来实现整个集群的对外一致性。其写过程大概变成了下面酱紫：

也就是在一个节点写完以后，使用一致性协议使整个集群达到一致，而后就能够返回了。指的注意的是，整个集群达到一致，可不是说每一个节点都ACK了。经过一致性协议，要比等每一个slave都ACK更快，还能让整个DB集群实现多节点写入，对于DB集群的性能来讲，天然会有不小的性能提高。根据MySQL官方文档，MGR有两种模式：

single-primary mode：只有主节点负责写，集群可以自动选举主节点

multi-primary mode：全部节点都接受写

贴一下MySQL对于group replication的文档和其性能测评：

文档：https://dev.mysql.com/doc/refman/5.7/en/group-replication.html

性能对比：http://mysqlhighavailability.com/performance-evaluation-mysql-5-7-group-replication/

3、一致性协议

MGR使用了paxos协议来实现集群的一致性。先贴一个分布式系统一致性问题的演示动画：

http://thesecretlivesofdata.com/raft/

协议挺复杂的，咱不就介绍了，明确两个点就得了：

1. 在paxos算法中，过半数的节点赞成变量v = 2了，就叫达成一致了

2. 在没一轮写入以后，经过节点之间相互通讯、投票，趋于实现达成一致