mysql读写分离与分库分表

读写分离

mysql读写分离实际利用的是主从复制架构，主数据库主要处理写操作，读请求被路由到从数据库来减少数据库压力。

存在的问题

1. 从数据库的数据相较于主数据库有延迟，造成读不到新数据，且并发量越高，延迟问题越严重
2. 不能减轻写压力

如何解决

1. 问题1，在对数据有强正确性要求时，采用强制路由的方式使读操作落地主库
2. 问题2，使用分库分表

实现

1. proxy代理层（shardingproxy、mysqlproxy、mycat、atlas等）
2. 应用层（java：sharding-jdbc、TDDL等）

分库分表

mysql分库分表本质上是数据分片，数据被拆分到多个分片（库或表）中，可以实现扩容，并达到降低数据库的写压力的目的。

垂直拆分（分库或分表）

根据业务来拆分数据库，同一类业务的数据表拆分到一个独立的数据库，另一类的数据表拆分到其他数据库。

比如电商数据库按照业务垂直拆分为：订单数据库、用户数据库、商品数据库等，如下图：

优点：

• 拆分后业务清晰，拆分规则明确
• 系统之间进行整合或扩展很容易
• 按照成本、应用的等级、应用的类型等将表放到不同的机器上便于管理
• 方便实现动静分离，冷热分离的数据库表的设计模式
• 数据维护相对简单

缺点：

• 部分业务表无法Join,只能通过接口方式解决，提高了系统的复杂度
• 受每种业务的不同限制，存在单库性能瓶颈，不易进行数据扩展和提升性能
• 事务处理复杂

水平拆分（分库或分表）

垂直拆分后遇到单机瓶颈，可以使用水平拆分。相对于垂直拆分的区别是：垂直拆分是把不同的表拆到不同的数据库中，而水平拆分是把同一个表拆到不同的数据库中。

相对于垂直拆分，水平拆分不是将表的数据做分类，而是按照某个字段的某种规则来分散到多个库之中，每个表中包含一部分数据。简单来说，我们可以将数据的水平切分理解为是按照数据行的切分，就是将表中 的某些行切分到一个数据库，而另外的某些行又切分到其他的数据库中。如下图：

优点：

• 单库单表的数据能保持在一定的量级，有助于性能的提高。
• 切分的表结构相同，应用层改造较少，只需要增加路由规则即可。
• 提高了系统的稳定性和负载能力。

缺点：

• 切分后，数据是分散的，跨库join操作难和性能差
• 拆分规则难以抽象
• 分片事务的一致性难以解决
• 数据扩容的难度和维护量极大

存在的问题

1. 不再支持ACID，即需要考虑分布式事务问题
2. 跨库查询问题
3. 分布式唯一id生成问题
4. 跨节点Join问题
5. 跨节点合并排序和分页问题
6. 维护成本提高

实现

1. proxy代理层（shardingproxy、mysqlproxy、mycat、atlas等）
   • 优点：跨语言
   • 缺点：性能较低（中间经过一层代理，网络io）；不能将数据拆分到不同产品的数据库（如：SqlServer、PostgreSQL等）
2. 应用层（java：sharding-jdbc、TDDL等）
   • 优点：性能较高（在内存中直接处理拆分）；支持跨不同产品数据库
   • 缺点：不支持跨语言

数据库拆分原则

1. 优先考虑缓存降低对数据库的读操作。
2. 再考虑读写分离，降低数据库写操作。
3. 最后开始数据拆分,切分模式： 首先垂直（纵向）拆分、再次水平拆分。
   3.1. 首先考虑按照业务垂直拆分。
   3.2. 再考虑水平拆分：先分库(设置数据路由规则，把数据分配到不同的库中)
4. 最后再考虑分表，单表拆分到数据1000万以内。

参考：https://xdoctorx.blog.csdn.net/article/details/108763158