MySQL集群解决方案（1）：MySQL数据库的集群方案

1、系统架构存在的问题

在我们的系统架构中，DBserver方面我们只是使用了单节点服务，如果面对大并发，海量数据的存储，显然单节点的系统架构将存在很严重的问题，所以接下来，我们将实现MySQL的集群，来应对大并发、海量数据存储等问题。

2、MySQL数据库的集群方案

2.1、读写分离架构

2.1.1、说明

我们一般应用对数据库而言都是“读多写少”，也就说对数据库读取数据的压力比较大，有一个思路就是说采用数据库集群的方案：其中一个是主库，负责写入数据，我们称之为：写库；其它都是从库，负责读取数据，我们称之为：读库；

那么，对我们的要求是：

1. 读库和写库的数据一致；

2. 写数据必须写到写库；

3. 读数据必须到读库；

2.1.2 架构

从该系统架构中，可以看出：

数据库从之前的单节点变为多节点提供服务
主节点数据，同步到从节点数据
应用程序需要连接到2个数据库节点，并且在程序内部实现判断读写操作

这种架构存在2个问题：

（1）应用程序需要连接到多个节点，对应用程序而言开发变得复杂

这个问题，可以通过中间件解决
如果在程序内部实现，可使用Spring的AOP功能实现

（2）主从之间的同步，是异步完成，也就意味着这是弱一致性

可能会导致，数据写入主库后，应用程序读取从库获取不到数据，或者可能会丢失数据，对于数据安全性要求比较高的应用是不合适的
该问题可以通过PXC集群解决

2.2 中间件

通过上面的架构，可以看出，应用程序会连接到多个节点，使得应用程序的复杂度会提升，可以通过中间件方式解决，如下：

从架构中，可以看出：

应用程序只需要连接到中间件即可，无需连接多个数据库节点
应用程序无需区分读写操作，对中间件直接进行读写操作即可
在中间件中进行区分读写操作，读发送到从节点，写发送到主节点

该架构也存在问题，中间件的性能成为了系统的瓶颈，那么架构可以改造成这样：

这样的话，中间件的可靠性得到了保证，但是也带来了新的问题，应用系统依然是需要连接到2个中间件，又为应用系统带来了复杂度。

2.3 负载均衡

为了解决以上问题，我们将继续优化架构，在应用程序和中间件之间增加proxy代理，由代理来完成负载均衡的功能，应用程序只需要对接到proxy即可。·

至此，主从复制架构的高可用架构才算是搭建完成。

2.4 PXC集群架构

在前面的架构中，都是基于MySQL主从的架构，那么在主从架构中，弱一致性问题依然没有解决，如果在需要强一致性的需求中，显然这种架构是不能应对的，比如：交易数据。

PXC提供了读写强一致性的功能，可以保证数据在任何一个节点写入的同时可以同步到其它节点，也就意味着可以存其它的任何节点进行读取操作，无延迟。

架构如下：

2.5 混合架构

在前面的PXC架构中，虽然可以实现了事务的强一致性，但是它是通过牺牲了性能换来的一致性，如果在某些业务场景下，如果没有强一致性的需求，那么使用PXC就不合适了。所以，在我们的系统架构中，需要将这两种方式综合起来，这样才是一个较为完善的架构。