主从延迟导致数据不一致的补偿策略 - 问题详情 - 创脉思

解读

在国内日均百万级订单的电商、金融或SaaS场景里，MySQL 主从几乎是标配：主库写、从库读，读写分离后 QPS 提升 3～5 倍。但主从延迟（Seconds_Behind_Master ≠ 0）带来的“刚下单却查不到订单”是面试高频痛点。面试官想听你：

延迟根因：大事务、DDL、单线程 SQL 线程、网络抖动、从库高负载
监控体系：
- 机器层：zabbix/prometheus 采集 Seconds_Behind_Master、Relay_Log_Pos 差值
- 应用层：在 PHP 请求生命周期里埋点，记录“写后读”时间窗口内的延迟命中次数
业务一致性模型：
- 强一致：0 延迟，必须读主库
- 最终一致：允许 500 ms 内不一致，可接受异步补偿
补偿手段：
- 读主库降级
- 二次异步查询 + 前端轮询
- 延迟队列对账
- 基于 GTID/位点的幂等重放
- 用户提示 + 客服工单
PHP 实现要点：
- 使用 PDO 的 setAttribute(PDO::ATTR_PERSISTENT) 维护主从双连接池
- Laravel/Symfony 里切换 read/write 连接，封装 DelayedReadException
- 利用 Swoole/Redis 延迟队列做对账任务，消费时幂等判断
降级开关：
- 配置中心（Apollo/Nacos）动态推送“强制读主”比例，支持按用户维度灰度
回滚与监控：
- 补偿失败触发钉钉/飞书告警，写入 ELK，方便追踪单条订单轨迹

“遇到主从延迟，我按‘事前防护、事中兜底、事后对账’三层处理，代码全部写在 PHP 公共库里，业务方零侵入。

事前防护
a. 监控：Prometheus 每 5 s 拉取 show slave status，延迟 >1 s 即告警；PHP 端在写请求后 500 ms 内发起的读请求都会打标 need_strong，记录命中率。
b. 参数优化：把从库升级为 8.0 并行复制，binlog_row_image=MINIMAL，关闭 log_slave_updates，降低 30% 延迟。
事中兜底
a. 强制读主：
- 对订单、支付、库存等强一致场景，写入 Redis 一个 order_id:{主键} -> 1 的 TTL=2 s 的键；PHP 查询层发现该键存在则直接走主库连接。
- 代码示例（Laravel）：
```
public function scopeConsistent($query, $id) {
    if (Redis::get("force_master:$id")) {
        $query->useWritePdo();
    }
    return $query;
}
```
b. 异步补偿 + 前端轮询：
- 对评论、点赞等弱一致场景，先返回“提交成功”，同时把订单 ID 写入延迟队列（Swoole\Timer::after 800 ms 后消费）；若 800 ms 后从库仍查不到，再触发一次“读主”回填缓存，并告警。
  c. 用户提示：
- 延迟 >3 s 且命中关键业务，前端弹层“数据同步中，稍后将自动跳转”，避免用户重复提交。
事后对账
- 每日凌晨用 Binlog + GTID 做增量校验，把主库订单表 hash 值与从库对比，不一致自动产出修复 SQL，通过 pt-online-schema-change 重放，保证次日 0 点前归零。
- 补偿任务全部接入公司统一任务平台，支持手动重试、幂等校验（用 order_id + unique_key 唯一索引防重）。

上线三个月，延迟 >500 ms 的查询占比从 0.9% 降到 0.05%，零用户投诉。”