主要作用：

数据安全性

给主服务增加一个数据备份。基于这个目的，可以搭建主从架构，或者也可以基 于主从架构搭建互主的架构。

读写分离

对于大部分的JAVA业务系统来说，都是读多写少的，读请求远远高于写请求。当主服务的访问压力过大时，可以将数据读请求转为由从服务来分担，主服务只负责数据写入的请求，这样大大缓解数据库的访问压力。 mysql主从同步机制保证了数据的单向传递，可以让多个节点和master数据保持一致，为了保证数据一致性，可以控制从节点只读，MySQL的主从架构只是实现读写分离的一个基础。具体的读写分离则需要一些中间件来支持，比如ShardingSphere。

故障转移-高可用

当MySQL主服务宕机后，可以由一台从服务切换成为主服务，继续提供数据读写 功能。 对于高可用架构，主从数据的同步也只是实现故障转移的一个前提条件，要实现 MySQL主从切换，还需要依靠一些其他的中间件来实现。比如MMM、MHA、 MGR。

实现原理

MySQL服务的主从架构一般都是通过binlog日志文件来进行的。即在主服务上打 开binlog记录每一步的数据库操作，然后从服务上会有一个IO线程，负责跟主服务 建立一个TCP连接，请求主服务将binlog传输过来。这时，主库上会有一个IO dump线程，负责通过这个TCP连接把Binlog日志传输给从库的IO线程。接着从服 务的IO线程会把读取到的binlog日志数据写入自己的relay日志文件中。然后从服务 上另外一个SQL线程会读取relay日志里的内容，进行操作重演，达到还原数据的目 的。我们通常对MySQL做的读写分离配置就必须基于主从架构来搭建。

 

数据同步有几种模式

异步复制

默认情况下，mysql的主从复制是异步处理的，Master一个线程只负责将数据写入binlog立刻提交事务返回响应，另一个线程负责dump的IO,如果master出现宕机，则从节点会丢失没有同步的数据，造成数据不一致

 

全复制

指当主库执行一个事务时，需要保证所有从节点都完成同步，执行完replay才认为成功，延迟消耗巨大

半同步复制

兼顾数据安全和延时时效，只需要保证有一台从节点完成将binlog操作写入replay日志即可，立即提交commit，不关注replaylog是否无法完成重演。默认会等10秒，如果超过10秒没有收到ack，就会降级成为异步复制，如果从节点挂掉，需要每次超时响应后才可以处理

 

高可用架构

MMM（Master-Master replication manager for Mysql）

主主复制管理器，可以对mysql集群进行监控和故障迁移，但同时只有一个主节点对外提供写操作，在主节点挂掉的时候，会通过vip的ip飘逸技术，将ip挂到另一个主节点下，属于主备模式

 优点：工具包相对比较完善，不需要额外的开发脚本

缺点：

       处理故障简单粗暴，没有数据补偿，容易丢失事务，建议采用半同步复制方式，减少失败概率

        目前MMM社区已经缺少维护，不支持基于GTID的复制

MHA（Master High Availability Manager）

最成熟和流程的高可用架构：多主多从的架构，当主节点挂掉时，会自动将拥有最近数据的从节点升级到主节点，MHA能够在30秒内实现故障切换，并能在故障切换过程中，最大程度的保证数据一致性

 优点：

        MHA除了支持日志点的复制还支持GTID的方式

        MHA会尝试从旧的Master中恢复二进制日志，只是未必每次都能成功。单能更少的丢失数据

缺点：

        MHA需要自行开发VIP飘逸脚本，比较繁琐

        MHA只监控Master，而不会监控slave

MGR(Mysql Group Replication)

类主要是解决传统异步复制和半同步复制的数据一致性问题。似于Paxos的变种，一个事务提交后，需要集群中的过半节点执行成功才算成功

分库分表

为什么需要分库分表

        单表压力，阿里巴巴的开发手册建议单标记录超过500万或者存储超过2G的就要建议分库分表了，最好按三年的量进行评估

垂直分库

        按业务将一张表的多个字段，拆到多个库的多个表中，可以分散读写压力但是当mysql单标数据量过大的时候，性能任然会急剧下降

水平分库

        主键id取模

        用id取模平均拆分到多个库的多个表中，好处是数据平均分布，坏处是后期很难扩展，对于订单和商品这种后期无限增加的数据来说，有限的库表后期很难支撑，

 

 范围分表

        按时间将每年或每个季度的数据进行拆分，区分冷热数据

        优势：可以很好地支持扩展，

        劣势:每年的数据不一样分布不均匀，

        可能一个季度的数据就超过了500万，可能需要复合拆分规则进行处理

 枚举分表

        比如按地区，按类目进行分表

分布分表引发的问题

        1、分布式事务，当然微服务本身就存在分布式事务，会诱发数据一致性问题，需要尽量避免

        2、运维维护成本，面对散乱的分库分表之后的数据，应用开发工程师和数据库管理员对数据库的操作都变得非常繁重。对于每一次数据读写操作，他们都需要知道要往哪个具体的数据库的分表去操作。

        3、需要注意主键冲突，一单用了分库分表，数据库的主键约束和唯一约束就不起作用了，需要人为生成主键，一般使用雪花算法和UUID

        4、无法关联查询，当业务表被拆分到多个数据库后，无法像以前那样可以join查询，只能多次查询到内存中处理

        5、跨阶段的排序，分页，需要去多个节点查询进行聚合再次排序，数据量大就容易导致内存溢出，很多查询都需要使用到ES处理