MySQL 读写分离

MySQL 读写分离是应对高并发、高流量场景下提升数据库性能和可用性的经典架构手段。它的核心思想非常简单让主库Master专职负责写操作而让一个或多个从库Slave/Read Replicas分担读操作。之所以要这么做是因为在大群互联网应用中读的压力往往远大于写比如电商浏览商品 vs 下单比例可能是 10:1 甚至更高。核心架构与工作原理读写分离的实现必须依赖MySQL 主从复制Replication。写操作INSERT/UPDATE/DELETE应用程序将所有写请求发送到Master主库。数据同步主库数据发生变更时会将修改记录到binlog二进制日志中。从库通过异步或半同步的方式读取该日志并在本地重放Relay Log从而保持数据与主库一致。读操作SELECT应用程序或中间件将读请求分发到一个或多个Slave从库。读写分离的两种实现方案如何让应用正确地把“写”丢给主库“读”丢给从库目前业界主要有两种技术路线1. 代码层/客户端实现如 ShardingSphere-JDBC, Spring RoutingDataSource原理在应用程序内部引入支持读写分离的 SDK/数据源驱动在执行 SQL 前进行解析如果是SELECT就走从库连接池如果是INSERT/UPDATE就走主库连接池。优点性能极高没有中间件的额外网络损耗架构简单不需要部署额外的硬件或服务。缺点与编程语言强绑定升级改动需要重启应用且无法统一管理连接。2. 中间件/代理层实现如 MyCat, ProxySQL, MaxScale原理在应用和数据库之间部署一个代理服务器Proxy。应用把代理当成标准的 MySQL 来看待代理层负责解析 SQL 并做路由分发。优点对后端代码完全透明业务开发不需要关心读写分离逻辑支持多语言方便进行监控和限流。缺点多了一层网络转发带来微小的性能损耗通常在几毫秒内中间件本身成了单点需要做高可用HA。核心痛点主从同步延迟刚性问题读写分离带来性能红利的同时也伴随着一个业界公认的难题——主从复制延迟。因为主从复制默认是异步Async的主库写完立刻返回成功此时从库可能还没来得及同步。如果用户刚发了帖子写主库刷新页面时请求走从库数据还没同步过去用户就会发现“帖子不见了”。常见的破局方案业务强制判定关键业务读主库涉及资金、个人中心修改、订单支付等对实时性要求 100% 的敏感场景直接强制读主库。动态追踪基于 Hint 或时间戳Hint 技术在 SQL 前加上特殊注释如/*master*/ SELECT * FROM ...强制该查询走主库。缓存过渡法写操作发生后在 Redis 里记录一个短期的标记如user_lock_123 1过期时间 2 秒。在标记存在期间该用户的读请求全部路由到主库等主库同步完成后再恢复读从库。升级复制机制开启 MySQL 的半同步复制Semi-Sync或使用MGRMySQL Group Replication架构至少确保有一个从库收到了日志再返回成功以此降低延迟概率。