MySQL数据库的集群方案

读写分离结构（主从）

读多写少，也就是对数据库读取数据的压力比较大。

其中一个是主库，负责写入数据，成为写库；其他都是从库，负责读取数据，成为读库。

对我们的要求：

读库和写库的数据一致；
写数据必须写到写库；
读数据必须到读库；

集群方案与单节点的差异：

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

这种方案的缺点：

应用程序需要连接到多个节点，对应用程序而言变得复杂；
- 这个问题可以通过中间件解决；
- 如果在程序内部实现，可使用Spring的AOP功能实现；
主从之间的同步，是异步完成，也就意味着是弱一致性；
- 可能会导致数据写入主库后，应用程序读取从库获取不到数据，或者可能会丢失数据，对于数据安全性要求比较高的应用是不合适的；
- 该问题可以通过PXC集群解决；

中间件

应用程序会连接到多个节点，使得应用程序的复杂度提升，可以通过中间件方式解决。

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

这种方式的架构也存在问题，中间件的性能成为系统的瓶颈，但是可以使用多个中间件部署的方式进行缓解。

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

负载均衡

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

PXC集群架构

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

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

混合架构

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

主从复制原理

MySQL主(master)从(slave)复制的原理：

master将数据改变记录到二进制日志(binary log)中，即配置文件log-bin指定的文件(这些记录叫做二进制日志时间，binary log events)；
slave将master的binary log events拷贝到它的中继日志(relay log)；
slave重新执行中继日志中的事件，将改变反映它自己的数据(数据重演)；

主从配置需要注意的地方：

主DB server和从DB server数据库的版本一致；
主DB server和从DB server数据库数据结构、数据一致；
主DB server开启二进制日志，主DB server和从DB server的server_id都必须唯一；