主从同步延迟是核心痛点
一、为什么会不同步？（延迟成因）
主从复制本质是异步：主库提交事务后立即返回客户端，从库通过 IO_THREAD 拉取 binlog 并重放（SQL_THREAD）。
延迟来源：
从库硬件差（磁盘慢、CPU弱）
主库写入压力大，binlog 产生速度超过从库重放速度
从库承担了大量复杂查询，占用资源
网络延迟
大事务（如一次删除百万行）在从库重放时阻塞
二、保证同步的方法（追求强一致）
方案 原理 优点 缺点
强制读主库 对一致性要求高的操作（如转账后立即查询余额），让代码判断路由到主库 100% 准确，无延迟 增加主库压力，无法发挥读写分离的扩展性
半同步复制 主库至少等待一个从库确认收到 binlog 后才返回客户端 基本不丢数据，延迟可控（等待一个 ack） 如果从库网络抖动，会阻塞主库写入；MySQL 5.7+ 支持 AFTER_SYNC 模式
组复制（MGR） 基于 Paxos，所有节点同步写入，强一致 真正强一致，自动故障切换 性能下降（写放大），只适合写少读多场景
等待从库位点 写入后，查询前检查从库的 Seconds_Behind_Master 或 binlog 位点，等它追上 应用层可控 增加复杂度，可能超时或死等
实际生产最常用：关键链路强制读主 + 普通查询走从库。例如：注册后立即登录 → 读主库；发布文章后作者自己刷页面 → 读主库；其他用户浏览 → 读从库。
三、同步出现延迟后如何处理？（补偿与兜底）
既然延迟无法 100% 消除，必须有应对方案：
- 监控与告警
持续监控 Seconds_Behind_Master（注意它超过 MAX_ALLOWED_PACKET 会重置为 0，不够准确）。
更可靠：监控 Master_Log_File 和 Read_Master_Log_Pos vs Relay_Master_Log_File 和 Exec_Master_Log_Pos，计算位点差距。
设置阈值（如延迟 > 5秒）触发告警，自动切换读写策略。
- 业务容忍设计
多数场景（评论、点赞、非实时排行榜）允许短暂不一致，用户刷新后自然可见。
前端可做“乐观展示”：用户提交动作后，前端先本地更新 UI，后台异步确认。即使从库暂时没数据，用户感受不到。
- 延迟补偿机制
读取降级：检测到延迟超过阈值时，将该请求临时切到主库（需要负载均衡器或数据库中间件支持）。
缓存兜底：写操作后更新 Redis（设置较短 TTL），读请求优先查缓存，缓存未命中再查从库。
异步修复：定时任务扫描主从差异表，修复不一致数据。
- 从库追赶加速
多线程并行复制（MySQL 5.7+ 的 slave_parallel_workers，8.0 默认 logical_clock 模式），大幅提升重放速度。
提升从库硬件（SSD、更多 CPU）。
避免从库执行复杂 ANALYZE、大查询（可临时关闭从库查询服务，专心同步）。
拆解大事务：DELETE ... LIMIT 1000 循环提交。
- 最终一致性的兜底预案
如果延迟长期无法解决，主动进行主从切换：将原从库提升为主库，并修复数据。配合 pt-table-checksum + pt-table-sync 工具修复不一致。