MySQL-集群

1.概述

由于高并发和分布式的兴起，使得MySQL数据库单节点已经不能满足生产日常的要求了，所以就有了MySQL集群的搭建。
针对于常用的MySQL集群，主要有PXC和RP两种模式。

2. PXC

PXC 全称 Percona XtraDB Cluster，它是基于mysql自带的一种集群技术 Galera做的改进来实现的一种数据库集群方案，它有一个很明显的特点就是任何节点都是可读写的，都可以被充当主节点来使用的。
它是数据强一致性的，只要在任何一个节点种写入数据其他的节点种肯定会同步到这条数据的。

2.1 PXC原理：

我们使用UML图来介绍一下PXC的执行过程。

这里我们用PXC中3个DB节点来介绍其原理，分别是DB1 DB3 和DB3, 数据的同步使用PXC。
先从clent说起 clent在执行insert del update 的时候，正常db1会给我们返回执行的结果，如果我们不提交事务的话是不能持久化到数据库中的，我们想要真实的持久化就必须要提交事务。
这里在提交事务的时候不仅仅要在当前节点里面持久化数据还要在其他节点持久化数据，毕竟我们是在pxc环境中操作的。
首先在提交事务的时候,db1会把数据传递给pxc，pxc会复制当前节点的数据，然后分发给DB2和DB3，分发后要做的就是持久化这些数据。
事务的执行操作在pxc中会生产一个GTID编号，然后由db2 和db3去分别执行这个事务，每个db执行完成后会把结果返回给db1,然后db1收到其他db的执行结果后在本地也执行一下GTID的这个事务，db1执行完成后没问题的话最终会把执行的结果返回给客户端。
通过这个时序图我们可以知道在pxc中的数据强一致，肯定是所有的数据库中的数据都是一致的。
注意：
1.在PXC中，生成的ID有可能是不连续的，如果期望连续就需要将ID生成策略提高一级，比如放在数据切分中间件中，如mycat等。或者在程序中执行ID的赋予问题。在赋予ID时需要考虑到后期可能迁徙数据库的问题。
2.PXC集群数量建议为奇数，防止脑裂。

2.2 PXC集群方案：

我们先是采用目前最主流的PXC方案把数据库集群在一起。
PXC它最大的特性就是读写强一致并且每个节点都是可以作为读写的入口，这种方案的好处就是我们无论在任何一个节点写入数据那么其他的库肯定会同步到这条数据，绝对绝对不会出现说在A库上面写数据然后B库查不到这种假设。
我们使用 haproxy 负载均衡中间件，当HA接收到一个增删改查的请求时他会把你的sql语句路由分发到不同的PXC节点让他们去分别执行。

那么你以为这样的设计就Ok了？我告诉你这样是远远不够的，我们知道mysql有一个性能瓶颈就是单表数据超过2000W 那么它的性能会急剧下降，所以我们在操作的时候要尽量避免单表存储的数据超过2000W。
那么这时候我们就要涉及到另外一个概念 数据切分，所以数据切分我们还是采用同样的PXC集群方案如下图：

这里我们使用MyCat做数据切分，MyCat是阿里开源的一个mysql数据切分中间件，支持离散分片（枚举，程序指定分区，十进制求模，字符串hash，一致hash）和连续分片（自定义数字范围，按日期分，按单月小时，按自然月分）等mysql数据库分片策略。

这里有个术语叫做分片，例如上图中集群1是一个分片区，集群2是另外一个分片区。
我们在执行一个Insert sql语句的时候mycat就可以根据指定的策略来存储我们的数据，例如按照月份把1月、3月、5月的数据存储到集群1中，其他月份的存储在集群2中。

采用这种方案我们就避免了mysql单表的性能瓶颈，如果2个集群不够就在加集群，使劲加加ok。纵览全局这样才是一个比较好的mysql集群方案。
但是，这样还没有完，PXC集群方案是以牺性能为代价的，所以才保证了数据库的强一致性，所以你的pxc数据库越多性能就会越低，接下来我介绍另外一种集群方案Replication。

3. RP

RP即Replication，主从复制。
即只能从主到从进行同步，采用主写副读，只有主节点有事务，RP方式下如果主节点没有同步到从节点，会出现数据不一致性。

3.1 RP集群方案：

Replication这种方案不会牺牲性能，但是有个问题就是非强一致性，例如你在DB1中写入数据可能会因为网络抖动在DB2中查询不到数据，这时候客户端接收到的状态是已经操作成功。
另外有一点是这种集群方案只能在一个节点中做写入操作，因为他的底层同步原理是单向同步的。

这种方案我们也会有mysql单表2000W数据瓶颈，我们也要做数据的切分，这里也会用mycat这个中间件来做数据切分，如下图：

4. 总结

以上2种方案，一种是数据强一致性，一种是非强一致性。
强一致性的话可以用来保存一些有价值的数据例如订单，支付等。
非强一致性方案可以用来保存用户的操作或者用户行为浏览等数据。
一个大型系统中单采用某一种方案是不够的。下面我们演进为2种方案结合使用如下图。

我们可以根据不同的业务和数据等级让MyCat来分片决定要把数据落到哪个库上。

PXC与RP对比

pxc 采用的是同步复制，事务在所有集群中要么全提交要么不提交，保证了数据的一致性。它写入数据速度慢
replication 采用的是异步复制，无法保证数据的一致性。它写入数据速度快。

这2种方案仅仅是都实现了数据的同步，没有数据切分功能。

对比项	PXC	RP
同步方式	同步	异步
主节点数量	全部都是	只有1个
同步方向	互相同步	只能主到从
读写关系	全部读写	主写副读
是否有事务	所有节点都有	主节点有
强一致性	是	否
执行效率	低	高
适用场景	订单、红包等贵重功能	通知、日志等次要功能

最佳实践：pxc与replication方案根据业务组合使用

pxc方案存储高价值数据，如：账户、订单、交易数据等..
replication方案存储低价值数据，如：通知、日志等..
用其他的中间件如mycat来切分数据管理集群。

参考文章：https://www.sohu.com/a/296980325_468635
参考文章：//www.greatytc.com/p/bb0939ae5a33