-
前言：为什么日志 + 可观测性也不足以解决所有线上问题？
- 分布式系统不是单点可重现
- 用户行为、状态、调用链变化巨大
- 很多线上问题：本地复现不了、测试环境复现不了、灰度环境复现不了
这就是“Replay Debug”的价值。
-
Replay Debug 的核心思想
- 把线上一次真实请求的“上下文 + 输入 + 依赖返回”完整捕获
- 在离线环境 100% 重现
- 让开发像调试本地代码一样调试线上问题
-
可回放体系四大核心要素
-
输入捕获（Input Capture）
- HTTP 请求
- 参数
- 身份信息
- Headers / TraceId
-
依赖结果记录（Dependency Snapshot）
- DB 查询结果快照
- Redis 查询快照
- 下游 RPC 结果
- MQ 事件状态
-
回放隔离环境（Replay Sandbox）
- 与线上隔离
- 与真实数据隔离
- 与真实下游隔离（全 Mock）
-
调试工具链
- 完整的调用链
- 断点/单步调试
- 事件回放时间线
-
-
技术难点
- 如何捕获依赖返回，不影响性能？
- 如何解决回放时的时间相关逻辑？
- 如何处理幂等接口？
- 事件链超长如何截断？
-
企业级落地架构
- Replay Collector（数据采集）
- Replay Storage（压缩 + 存档）
- Replay Runner（基于 JVM/Sandbox 回放）
- Replay Diff（结果比对，找不同）
-
真实案例：一次“支付超时”难以复现问题的 Replay Debug 演示
- 快速定位到：MQ 投递延迟 + Redis 热 Key + 某个边界分支
- 无 Replay Debug 需要 2 天
- 有 Replay Debug 只需要 10 分钟
-
总结
- Replay Debug 是“大厂级工程能力”的核心组件
- 有 Replay 才能真正做到快速、精准、可解释的线上排障
