MySQL读写分离与分库分表

大流量下MySQL问题

磁盘IO瓶颈：热点数据太多，缓存放不下
网络IO瓶颈：请求的数据太多，网络带宽不够
CPU瓶颈：单表数据量太大，扫描数据太多，SQL效率低。
解决方案：
单机->分布式集群
分库分表(shardingSphere,mycat,DBLE…)
NewSQL(postgresql,voltdb,tiddb…)

什么是读写分离

互联网场景，读多写少

写入 在主库

查询 在从库

主从同步

从库 起两个线程，IOThread 线程拷贝主库binlog,SQLThread读取binlog写入从库

强制路由：

问题：因为主从同步的时候需要走网络，极端情况下会出现延迟，导致数据不能及时同步，上述场景在极端情况下slave从库会没有此订单数据。

atlas解决方案

查询语句加注解/*master*/强行查主库数据

什么是分库分表

垂直拆分：

1.每个库(表)的结构都不一样

2.每个库(表)的数据都(至少有一列)一样

3.每个库(表)的并集是全量数据

优点：

1.拆分后业务清晰(专库专用按业务拆分)

2.数据维护简单，按业务不同，放到不同机器上

缺点：

1.如果单表数据量大，写读压力依然很大，

2.受某种业务限制，也就是说一个业务往往会影响到数据库的瓶颈(性能问题)

3.部分业务无法关联join,只能通过java接口去调用，提高开发复杂度

水平拆分：

1.每个库(表)的结构都一样

2.每个库(表)的数据都不一样

3.每个库(表)的并集是全量数据

优点：

1.单库(表)的数据保持在一定的量，有助于性能提高

2.提高了系统的稳定性和负载能力

3.切分表的结构相同，程序改造较少

缺点：

1.数据的扩容很有难度维护量大

2.拆分规则很难抽象出来

3.分片事务的一致性的问题，部分业务无法关联join，只能通过java程序接口去调用

分库分表中间件

proxy代理层：(性能比jdbc应用层差，但支持跨语言)

mycat,atlas,mysql-proxy,ShardingProxy

jdbc应用层:(不支持跨语言，性能好)

ShardingSphere(生态圈),TDDL

分库分表带来的问题

1.主键重复问题，如何避免
2.公共表处理
3.事务一致性
4.跨节点关联查询
5.跨节点分页，排序函数