主从复制延迟处理

刚下单，订单列表里看不到——主从延迟导致的”写后读不一致”问题，怎么排查和解决？

一、主从复制的原理

• 1.1 异步复制——主库不等待从库
• 1.2 binlog 传输——IO 线程接收 → Relay Log → SQL 线程执行
• 1.3 延迟产生的原因——SQL 线程是单线程的（5.6 之前）

二、延迟的度量

• 2.1 SHOW SLAVE STATUS——Seconds_Behind_Master
• 2.2 注意——为 NULL 或 0 不代表没有延迟
• 2.3 Percona Toolkit——pt-heartbeat 更精确

三、延迟的常见原因

• 3.1 主库大事务——binlog 量大
• 3.2 从库性能不足——跟不上主库
• 3.3 从库有其他查询负载——资源竞争
• 3.4 网络带宽不足

四、并行复制

• 4.1 MySQL 5.6——按库并行（slave_parallel_workers）
• 4.2 MySQL 5.7——LOGICAL_CLOCK，组提交并行
• 4.3 MySQL 8.0——WRITESET，基于行冲突检测
• 4.4 并行复制的配置

五、半同步复制

• 5.1 原理——主库等待至少一个从库确认收到 binlog
• 5.2 rpl_semi_sync_master_wait_for_slave_count
• 5.3 对主库性能的影响——增加了网络等待

六、写后读一致的解决方案

• 6.1 关键操作强制走主库——Hint 机制
• 6.2 等待从库追上——SELECT MASTER_POS_WAIT()
• 6.3 缓存层——写入后更新缓存
• 6.4 GTID 的使用

七、总结

• 主从延迟无法完全消除，只能减小
• 关键业务必须处理写后读一致性问题