**一、主从复制（Master-Slave Replication）基础**
读写分离依赖于 MySQL 的主从复制机制：
- **主库（Master）**：处理写操作（INSERT/UPDATE/DELETE），并将变更同步到从库。
- **从库（Slave）**：处理读操作（SELECT），数据来自主库的复制。
**配置步骤**：
1. 主库开启二进制日志（binlog）。
2. 从库配置主库信息，启动复制线程。
3. 主库执行写操作，binlog 记录变更，从库同步并应用变更。
**二、读写分离实现方式**
**1. 应用层实现**
**原理**：应用代码根据 SQL 类型（读/写）选择不同的数据库连接。
**示例（Java）**：
java
// 写操作连接主库
DataSource writeDataSource = getMasterDataSource();
Connection writeConn = writeDataSource.getConnection();
statement.executeUpdate("INSERT INTO users VALUES (...)");
// 读操作连接从库（负载均衡到多个从库）
DataSource readDataSource = getSlaveDataSource();
Connection readConn = readDataSource.getConnection();
resultSet = statement.executeQuery("SELECT * FROM users");
**优点**：
- 实现简单，无需额外中间件。
- 可自定义负载均衡策略。
**缺点**：
- 代码侵入性强，需维护多个数据源。
- 主从延迟可能导致读不一致。
**2. 中间件实现**
**原理**：在应用和数据库之间添加代理层，自动识别 SQL 类型并路由。
**常见中间件**：
- **MySQL Router（官方）**：轻量级代理，支持读写分离和负载均衡。
- **MaxScale（开源）**：功能丰富的 MySQL 代理，支持读写分离、分库分表等。
- **MyCat（开源）**：类似 MySQL 服务器，支持读写分离和分布式事务。
**架构图**：
应用 → 中间件 → 主库（写）
↘ → 从库1（读）
↘ → 从库2（读）
...
**优点**：
- 应用无感知，代码无需修改。
- 自动负载均衡和故障转移。
**缺点**：
- 引入额外组件，增加运维复杂度。
- 可能成为性能瓶颈。
**3. 客户端代理（如 ShardingSphere-JDBC）**
**原理**：在客户端通过 JDBC 驱动实现读写分离，类似应用层但更透明。
**示例配置**：
yaml
spring:
shardingsphere:
rules:
readwrite-splitting:
data-sources:
ds_master_slave:
type: Static
master-data-source-name: ds_master
slave-data-source-names: ds_slave_0,ds_slave_1
**优点**：
- 无中间件，性能损耗小。
- 支持复杂路由规则。
**缺点**：
- 每个应用都需配置，运维成本高。
**三、负载均衡策略**
**1. 随机/轮询**
- 从库列表中随机或按顺序选择，适合从库性能均匀的场景。
**2. 权重分配**
- 根据从库性能分配权重（如 `slave1:70%`, `slave2:30%`）。
**3. 基于负载**
- 根据从库负载指标（如 CPU、连接数）动态选择，需监控系统支持。
**四、主从延迟问题**
**问题场景**：
写操作后立即读，可能因主从延迟导致数据不一致。
**解决方案**：
1. **强制读主库**：
```java
// 写操作后强制从主库读
boolean forceReadMaster = true;
Connection conn = forceReadMaster ? getMaster() : getSlave();
```
2. **会话粘性（Session Sticky）**：
同一会话的读操作固定路由到主库，直到会话结束或超时。
3. **延迟感知**：
通过监控从库延迟（如 `SHOW SLAVE STATUS` 的 `Seconds_Behind_Master`），延迟过高时自动读主库。
**五、监控与高可用**
1. **主从复制监控**：
- 定期检查 `Seconds_Behind_Master`，确保延迟在可接受范围内（如 < 1 秒）。
2. **故障转移**：
- 主库故障时，自动提升从库为主库（需配合工具如 MHA、PXC）。
**六、适用场景与注意事项**
**适用场景**：
- 读多写少的业务（如内容平台、电商商品页）。
- 单库性能达到瓶颈，需分散读压力。
**注意事项**：
- **不适合写密集型场景**：主库仍是写瓶颈。
- **事务一致性**：跨库事务需谨慎处理（如尽量避免）。
- **从库数量限制**：过多从库会增加主库复制压力，通常建议 3-5 个。
**七、总结**
| 方案 | 优点 | 缺点 | 适用场景 |
|--------------|---------------------|---------------------|-------------------|
| 应用层实现 | 简单灵活 | 代码侵入 | 小规模系统 |
| 中间件 | 透明、自动负载 | 运维复杂 | 中大规模系统 |
| 客户端代理 | 性能高、规则灵活 | 配置分散 | 微服务架构 |
选择方案时需根据业务规模、技术栈和运维能力综合评估，必要时结合监控和自动化工具保障系统稳定性。