mysql集群方案这里介绍2种，PXC 和 Replication。

大型互联网程序用户群体庞大，所以架构设计单节点数据库已经无法满足需求。大家也深有体会，有一万人在学校网站查成绩或是选课的时候网站时常是访问不了或者相应特别特别慢。这种情况就凸显出来单机单节点上性能的不足。无论你使用什么样的数据库免费的或者付费的单机单节点都是无法承受某个点上面的并发的，另外一方面就是数据库没有做冗余设计。这时候我们就需要做集群和冗余保证数据库的高可用和高性能提升用户体验。

下面我们先来用一组数据来做数据库单节点压力测试：

1.使用5000个用户做5000次查询，平均下拉每个用户查询一次。

我们看到系统结果显示5000次并发的话执行的时间是 7.671秒，以上5000并发来讲的话数据库发挥还是比较正常的没有出现崩溃宕机。

2.下面我们把5000次并发和查询次数都增大1倍改成10000看看会出现什么情况。

如上当并发为10000的时候系统提示 没有那么多的连接应对并发的访问，系统拒绝了很多请求。最终执行的结果是48.547秒，这并不是说系统执行了我们所有的请求，它只是执行了一部分用了48秒。那么我们如果在网站上使用单机单节点的部署只要有1000并发访问那么系统马上崩溃！这还仅仅是1000个用户，那么对于搞电商的同学如何来应对运营的秒杀 促销活动？所以对于我们晨光这样的大公司在做数据库设计的时候一定采用集群集群集群这样的方案。

接下来我们介绍一下晨光科力普数据库集群是如何去设计搭建以及如何进化的。

1.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。

2.Replication方案介绍

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

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

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

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

3. PXC介绍

    PXC 全称 Percona XtraDB Cluster,它是基于mysql自带的一种集群技术 Galera做的改进来实现的一种数据库集群方案，它有一个很明显的特点就是任何节点都是可读写的，都可以被充当主节点来使用的。

并且他是数据强一致性的只要在任何一个节点种写入数据其他的节点种肯定会同步到这条数据的。

PXC原理：

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

这里我们用PXC中3个DB节点来介绍其原理，分别是DB1 DB3 和DB3, 数据的同步使用ＰＸＣ。

先从clent说起 clent在执行insert del up 的时候，正常db1会给我们返回执行的结果，如果我们不提交事务的话是不能持久化到数据库中的。我们想要真实的持久化就必须要提交事务。这里在提交事务的时候不仅仅要在当前节点里面持久化数据还要在其他节点持久化数据毕竟我们是在pxc环境中操作的。

首先在提交事务的时候,db1会把数据传递给pxc, pxc会复制当前节点的数据 然后分发给DB2 和DB3，分发后要做的就是持久化这些数据。

事务的执行操作在pxc中会生产一个GTID编号，然后由db2 和db3去分别执行这个事务，每个db执行完成后会把结果返回给db1,然后db1收到其他db的执行结果后在本地也执行一下GTID的这个事务db1执行完成后没问题问题的话最终会把执行的结果返回给客户端。

通过这个时序图我们可以知道在pxc中的数据强一致，肯定是所有的数据库中的数据都是一致的。

4: pxc与replication 方案优劣：

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

replication 采用的是异步复制，无法保证数据的一致性。它写入数据速度快。

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

5：pxc与replication 方案组合：

pxc方案存储高价值数据 如：账户 订单 交易数据等。。

replication 方案存储低价值数据：如 通知 日志 等。。

用其他的中间件如mycat来切分数据管理集群。

如果你觉得所有收获请多多支持。