单点服务存在的问题
单节点服务无法应对高并发，海量数据的存储，通过MySQL集群进行解决
MySQL集群方案
读写分离架构
主库负责写入数据，从库负责读取数据，同时读库和写库保持数据一致，适合读多写少的一般场景
- 应用程序需要连接到多个数据库节点，可通过中间件解决
- 主从同步是异步完成，意味着弱一致性，可通过PXC集群解决
主从复制原理
主从复制模式
- 基于SQL语句的复制（SBR），对应binlog的STATEMENT格式
- 基于行的复制（RBR），对应binlog的ROW格式
- 混合模式复制（MBR），对应binlog的MIXED格式
SBR模式不需要记录数据的变化，减少了日志量，但在某些情况下会出现数据不一致的问题
RBR模式记录数据的变化，不会出现数据不一致的问题，但是会产生大量日志
MBR模式结合以上两种模式的优点，根据执行的SQL语句选择采用SBR模式或者RBR模式
中间件
由中间件区分读写操作，中间件的性能可能成为系统的瓶颈
对中间件进行集群，但是又带来了应用层和中间件之间的负载均衡问题
Mycat数据库分库分表中间件
- MyCat实现读写分离
- MyCat实现数据分片
- MyCat实现集群
负载均衡
在应用层和中间件之间增加代理，由代理完成负载均衡功能
实际上代理只进行请求转发，资源消耗极小，可以做到很高性能
HAProxy实现负载均衡
PXC集群架构
PXC集群提供了强一致性功能，保证了数据写入某一节点的同时可以同步到其它节点
PXC集群
PXC集群架构和读写分离架构的区别
- PXC集群所有节点都是可读可写的，读写分离从节点不能写入数据，因为主从同步是单向的
- PXC集群同步机制是同步进行的，读写分离同步机制是异步进行的
- PXC集群性能低于读写分离，两者的应用场景不同
混合架构
PXC集群通过牺牲性能换取强一致性，根据业务场景的不同使用混合架构才是最优选择
