主从同步原理
主从同步结构：主库负责写数据，从库负责读数据，如图——
MySQL主从复制的核心就是二进制日志（BINLOG），它记录了所有的 DDL（数据定义语言）语句和 DML（数据操纵语言）语句，但不包括数据查询（SELECT、SHOW）语句。
具体的同步流程为：当主库的数据发生变化，会把操作语句写入到binlog的文件中；从库的IOthread专门从主库的binlog中读取数据；读取完成之后，就会把数据写入到从库的中继日志Relay log中；再由从库的SQLthread线程读取Relay log，并执行里面的命令；执行完成之后，主库与从库的数据就会保持一致。
复制分成三步：
- Master 主库在事务提交时，会把数据变更记录在二进制日志文件 Binlog 中。
- 从库读取主库的二进制日志文件 Binlog ，写入到从库的中继日志 Relay Log 。
- slave重做中继日志中的事件，将改变反映它自己的数据。
分库分表
主从架构虽然可以让读写分开操作，解决了分担了数据库的访问压力，但是不能解决海量存储的问题。
分库分表的时机：
- 前提，项目业务数据逐渐增多，或业务发展比较迅速（在企业项目中，单表的数据量达1000W或20G以后，就需要进行分库分表）
- 优化已解决不了性能问题（主从读写分离、查询索引…）
- IO瓶颈（磁盘IO、网络IO）、CPU瓶颈（聚合查询、连接数太多）
分库分表——解决海量存储问题：
拆分策略
垂直拆分： 包括垂直分库和垂直分表；
水平拆分： 包括水平分库和水平分表；
垂直分库： 以表为依据，根据业务将不同表拆分到不同库中。
特点：
- 按业务对数据分级管理、维护、监控、扩展
- 在高并发下，提高磁盘IO和数据量连接数
垂直分库，如图所示：
垂直分表： 以字段为依据，根据字段属性将不同字段拆分到不同表中。
拆分规则：
- 把不常用的字段单独放在一张表
- 把text，blob等大字段拆分出来放在附表中
特点：
- 冷热数据分离（经常被查询的数据称为热数据；相反，不常用的数据称为冷数据）
- 减少IO过渡争抢，两表互不影响
垂直分表，如图所示（注意在实际应用中，拆表不一定要在不同的库中进行，拆分成两个表就行了）：
水平分库： 将一个库的数据拆分到多个库中。
特点：
- 解决了单库大数量，高并发的性能瓶颈问题
- 提高了系统的稳定性和可用性
水平分库，如图所示：
路由规则：
- 根据id节点取模
- 按id也就是范围路由，节点1(1-100万 ),节点2(100万-200万)
- …
水平分表： 将一个表的数据拆分到多个表中(可以在同一个库内)。
特点：
- 优化单一表数据量过大而产生的性能问题;
- 避免IO争抢并减少锁表的几率;
水平分表，如图所示：
新的问题和新的技术
分库之后的问题：
- 分布式事务一致性问题
- 跨节点关联查询
- 跨节点分页、排序函数
- 主键避重
分库分表中间件：
- sharding-sphere
- mycat
使用分库分表中间件可以降低开发的难度，解决分库分表之后可能会遇到的问题：
总结——具体拆分策略：
- 水平分库，将一个库的数据拆分到多个库中，解决海量数据存储和高并发的问题
- 水平分表，解决单表存储和性能的问题
- 垂直分库，根据业务进行拆分，高并发下提高磁盘IO和网络连接数
- 垂直分表，冷热数据分离，多表互不影响
- 注意：使用水平拆分策略时，需要使用中间件（sharding-sphere、mycat）来避免分库之后可能遇到的问题。
)
