对于每个用户不一样的那些数据来说，缓存的命中率就没有那么高，还是有相当一部分查询请求因为命中不了缓存，打到 MySQL 上。随着系统用户数量越来越多，打到 MySQL 上的读写请求也越来越多，当单台 MySQL 支撑不了这么多的并发请求时，读写分离是提升 MySQL 并发的首选方案。
对于很多系统，数据库需要应对的绝大部分请求都是只读查询请求。
一个分布式的存储系统，想要做分布式写是非常非常困难的，因为很难解决好数据一致性的问题。但实现分布式读就相对简单很多，保证这这些只读实例上的数据都随时一样，这些只读的实例就可以分担大量的查询请求。
实施 MySQL 的读写分离方案。需要做两件事儿：
1.部署一主多从多个 MySQL 实例，并让它们之间保持数据实时同步。
2.分离应用程序对数据库的读写请求，分别发送给从库和主库。
MySQL 自带主从同步的功能，经过简单的配置就可以实现一个主库和几个从库之间的数据同步，部署和配置的方法，看MySQL 的官方文档照着做就可以。
分离应用程序的读写请求方法有下面这三种：
纯手工方式：修改应用程序的 DAO 层代码，定义读写两个数据源，指定每一个数据库请求的数据源。
组件方式：也可以使用像 Sharding-JDBC 这种集成在应用中的第三方组件来实现，这些组件集成在你的应用程序内，代理应用程序的所有数据库请求，自动把请求路由到对应数据库实例上。
代理方式：在应用程序和数据库实例之间部署一组数据库代理实例，比如说 Atlas 或者 MaxScale。对应用程序来说，数据库代理把自己伪装成一个单节点的 MySQL 实例，应用程序的所有数据库请求被发送给代理，代理分离读写请求，然后转发给对应的数据库实例。
如果配置了多个从库，推荐使用“HAProxy+Keepalived”这对经典的组合，来给所有的从节点做一个高可用负载均衡方案，既可以避免某个从节点宕机导致业务可用率降低，也方便后续随时扩容从库的实例数量。因为 HAProxy 可以做 L4 层代理，也就是说它转发的是 TCP 请求，所以用“HAProxy+Keepalived”代理 MySQL 请求。
注意读写分离带来的数据不一致问题
对于这种主从延迟带来的数据不一致的问题，没有什么简单方便而且通用的技术方案可以解决，我们需要重新设计业务逻辑，尽量规避更新数据后立即去从库查询刚刚更新的数据。