一、MySQL 主从复制
1. 核心概念
MySQL 主从复制是一种数据同步机制，通过配置将一台 MySQL 服务器（主库，Master）的数据变更实时同步到一台或多台 MySQL 服务器（从库，Slave）。
2. 核心价值
- 数据热备：从库作为主库的实时副本，用于数据备份与灾难恢复。
- 读写分离基础：为读写分离提供架构支撑，分散数据库压力。
- 故障转移：主库故障时，可快速将从库提升为主库，保障业务连续性。
- 负载分担：从库可独立承担数据分析、报表查询等离线任务。
3. 核心原理（异步复制）
主从复制基于 MySQL 的 Binlog（二进制日志） 实现，核心流程分为 3 步：
- 主库记录 Binlog：主库执行完写操作（增删改）后，将变更记录写入 Binlog 日志。
- 从库拉取 Binlog：从库的 I/O 线程连接主库，请求拉取指定位置的 Binlog，写入本地的 Relay Log（中继日志）。
- 从库重放 Relay Log：从库的 SQL 线程读取并执行 Relay Log 中的变更，将数据同步到本地。
4. 常见架构模式
- 一主一从：最简单的架构，适用于数据备份、小规模读写分离。
- 一主多从：最常用的架构，通过多个从库分担读压力，适用于读多写少的场景。
- 双主架构：两台服务器互为主从，均支持写操作，需注意数据冲突问题。
二、MySQL 读写分离
1. 核心概念
读写分离是指将读请求和写请求分发到不同的数据库服务器：
- 写请求：仅发送给主库（Master），保证数据一致性。
- 读请求：发送给从库（Slave），利用从库分担主库的读压力。
2. 核心价值
- 提升并发能力：通过多个从库并行处理读请求，大幅提升系统的读吞吐量。
- 保护主库：将大量读请求分流，避免主库因压力过大导致性能下降或宕机。
3. 主流实现方式
（1）应用层实现（代码层面）
- 原理：在业务代码中通过逻辑判断，将读写请求分别连接主库和从库。
- 代表工具：ShardingSphere-JDBC、Spring Boot + Dynamic DataSource。
- 优缺点：无需额外部署中间件，性能损耗小；但代码侵入性强，扩容需修改代码。
（2）中间件层实现（代理模式）
- 原理：在应用和数据库之间部署一层代理服务器，应用统一连接代理，由代理负责路由读写请求。
- 代表工具 ：
- Mycat：国产开源中间件，支持分库分表 + 读写分离，配置简单，适合中小企业（你正在部署的 Mycat 即为此类）。
- ShardingSphere-Proxy：Apache 顶级项目，功能全面，支持跨数据库。
- ProxySQL：高性能 MySQL 代理，侧重流量控制与故障转移。
- 优缺点：对业务代码无侵入，扩容灵活；但需额外维护中间件，有轻微性能损耗。
三、关键问题与解决方案
1. 主从延迟（最核心问题）
- 现象：主库写入数据后，从库需要一定时间才能同步完成，导致从库读取到 "旧数据"。
- 产生原因 ：
- 从库的 SQL 线程是单线程重放，若主库并发写压力大，从库同步速度跟不上。
- 网络延迟、从库硬件性能弱于主库。
- 缓解方案 ：
- 架构优化：采用半同步复制（保证至少一个从库收到 Binlog）或组复制（MGR）。
- 业务优化：对实时性要求高的读请求（如 "下单后立即查询订单"）强制走主库。
- 监控告警：通过
SHOW SLAVE STATUS监控延迟时间，设置阈值告警。
2. 数据一致性保障
- 读写分离架构下，需优先保证 "写后读" 的一致性，常见策略：
- 关键业务强制读主：如用户登录、支付、订单查询等核心场景，直接连接主库。
- 延迟判断路由：中间件判断从库延迟时间，若延迟过高，自动切回主库。
- 会话级路由：同一用户的写操作后，后续一段时间内的读操作均路由到主库。