MySQL主从复制-读写分离案例
MySQL主从复制-读写分离案例
面对日益增加的系统访问量，数据库的吞吐量面临巨大瓶颈。对于同一时刻有大量并发读操作和较少写操作类型的应用系统来说，将数据库拆分为主库和从库，主库负责处理事务性的增删改操作，从库负责处理查询操作，能够有效的避免由数据更新导致的行锁，使得整个系统的查询性能能得到极大的改善。
读写分离的前提是：你能接受一定程度的“读到旧数据”（因为主从复制通常是异步的，见 MySQL主从复制）。因此落地时要先把一致性策略想清楚。
关联：MySQL主从复制-配置前提 / 索引 / DQL
落地思路（从架构到代码）
读写分离常见三种实现方式：
- 应用层路由：代码里区分读库/写库（侵入性高，但透明可控）
- 中间件/代理：用代理层把 SQL 分发到主/从（对业务更透明）
- 客户端框架：在 JDBC 层做增强（典型是 ShardingSphere 的 Sharding-JDBC）
本仓库里给出的案例走的是第 3 种方式（Java 侧落地）。
必须补齐的“一致性策略”
- 读己之写（Read-Your-Writes）：写入后立刻读取同一份数据时，要读主库或开启“强制主库一段时间”的策略
- 事务内读写：事务里的读一般要走主库，否则可能读不到本事务写入的数据
- 延迟感知：从库延迟过大时，读请求应该降级到主库或返回提示
这些策略决定了读写分离是否“可用而不是偶发出错”。
风险与边界（上线前要想清楚）
-
从库延迟：高峰期/大事务会放大延迟，造成脏读体验
-
故障切换：主库挂了后谁来接管写入，需要配套高可用方案
-
写入压力：读写分离不一定解决写瓶颈；写瓶颈通常需要分库分表/业务拆分
下一步建议阅读顺序：