读写分离是提升 MySQL 并发的首选方案

和用户相关的信息，每个用户看到的信息不同，就没办法命中缓存了。

读写分离，实现简单。一般不需要修改系统的业务逻辑，只需要简单修改 DAO 代码，把对数据库的读写请求分开，请求不同的 MySQL 实例就可以了。

典型读写分离架构：

主库负责执行应用程序发来的所有数据更新请求，然后异步将数据变更实时同步到所有的从库中去。

如何来实施 MySQL 的读写分离方案。你需要做两件事儿：

1. 部署一主多从多个 MySQL 实例，并让它们之间保持数据实时同步。
2. 分离应用程序对数据库的读写请求，分别发送给从库和主库。

分离应用程序的读写请求方法有下面这三种：

1. 手工方式：修改DAO层代码，指定每个sql请求的数据源
2. 组件方式：可以使用Sharding-JDBC
3. 代理方式：应用程序连接代理，代理连接数据库。比如：Atlas或者MaxScale

推荐使用第2种，一般不推荐使用第3种，会加长链路有一定性能损失。

另外，如果你配置了多个从库，推荐你使用“HAProxy+Keepalived”这对经典的组合，来给所有的从节点做一个高可用负载均衡方案，既可以避免某个从节点宕机导致业务可用率降低，也方便你后续随时扩容从库的实例数量。

注意读写分离带来的数据不一致问题

对于这种主从延迟带来的数据不一致的问题，没有什么简单方便而且通用的技术方案可以解决，我们需要重新设计业务逻辑，尽量规避更新数据后立即去从库查询刚刚更新的数据。

可以使用的方法：

1. 可以容忍不一致，通过加上一些跳转页面，比如支付成功，拉长查询从库时间
2. 无法容忍不一致，把相关逻辑放到一个服务中，放在一个事务进行处理。

此文章为3月Day12学习笔记，内容来源于极客时间《后端存储实战课》