回放测试基础概念：录制-回放模式、数据来源与真实流量对比

做回放测试，首先得摸清楚三个关键问题：怎么录？录什么？放出来准不准？ 很多团队跑了一堆回放，结果跟线上表现对不上，最后发现是录制方式选错了，或者数据源本身就有偏差。今天咱们就把这三个根基掰开揉碎讲明白。

录制-回放模式：脱机还是在线？

录制回放的模式，说白了就两种走向：离线录制和在线录制。我最早接触这个领域时，就犯过一个低级错误——在一台已经跑着压测的机器上继续录数据，结果录下来的全是压测流量，根本不是真实用户行为。嗯，这不叫录制，这叫串扰。

下面这张表帮你快速区分两种模式的核心差异：

特征	离线录制	在线录制
触发时机	先录一段完整流量，存成文件或DB，之后再拉起回放	边录边放，实时或准实时
存储开销	需要磁盘/对象存储保存历史流量	内存/临时缓冲区，一般不持久化
典型工具	tcpcopy、gor、mitmproxy	Envoy Tap、阿里Pandora
适用场景	回归测试、容量规划、历史问题复现	线上冒烟、A/B流量验证、热修复验证
我踩过的坑	录了3小时数据，忘了裁剪无效请求，回放时长多出50%	实时回放时网络抖动导致录制端背压，丢包严重

我个人习惯：能用离线就别轻易上在线。离线录制让你有足够时间清洗、筛选、打标签，回放速度也能自己控制。在线录制虽然看着“实时”，但一旦回放环境与线上配置有差异，反而更难排查问题。你想想看，线上丢一个请求可能是客户端重试，回放时丢包却可能是环境瓶颈，你从回放结果里怎么分辨？

回放数据来源：流量从哪里来？

有了录制模式，下一步就是找数据。数据源头直接决定回放的可信度。我总结了三类常见来源，每类都有鲜明的特点：

• 生产真实流量：最理想的数据源。通过镜像端口、Agent抓包或服务网格（如Istio的mirroring）把用户请求复制一份。我建议优先选这个，因为它包含真实用户行为、参数分布、并发模型。
• 压测脚本构造：用JMeter/GoReplay等工具按业务模型生成的请求。适合做对比基线，但缺点是难以模拟异常参数和长尾行为。我记得有一次，安全团队要求测试SQL注入防御，用构造流量测了一周都没问题，结果线上被手工注入了——因为构造脚本根本没考虑Unicode编码的情况。
• 历史日志/离线Dump：从ELK、SLS等平台导出请求日志，回放时重新组装成HTTP请求。这条路径要注意时间戳对齐和session状态恢复。我曾经用一个凌晨3点的日志快照做回放，结果所有请求都带了过期的Cookie，回放成功率不到10%。后来加了一层Cookie刷新逻辑才搞定。

回放与真实流量的关键差异

很多人跑完回放，看到成功率99%，就以为跟线上一样了。事实远没那么简单。下面几个差异点，是我一次一次掉坑里总结出来的——说白了，回放是近似模拟，不是完美复刻。

对比维度	真实流量	回放流量
请求顺序	天然乱序，依赖前序响应	常按录制时间有序回放，缺少因果依赖
缓存状态	Redis/Disk热数据实时命中	回放时缓存可能已过期或未预热
网络延迟	真实RTT + 丢包 + 重传	可控延迟，通常忽略网络波动
并发模型	用户步调随机，Think Time不固定	均匀放量或按固定倍率加速
下游依赖	所有服务都在线且负载均衡	可能只有被测服务在线，mock掉下游
数据一致性	写操作真实落盘，会影响后续请求	写操作往往被拦截或只记录，不回写真实数据

举个例子。有一次我回放一个下单接口，成功率100%，但线上压测一晚上就挂了。为什么？因为回放时我Mock了商品库存服务，始终返回“有货”，而线上真实库存只有100件，并发一高直接抢空。所以回放只能告诉你系统在“理想状态下”的处理能力，真要测真实瓶颈，还需要在回放的同时注入某些真实依赖，或者做“半Mock”模式。

所以，我现在的做法是：先跑一轮全量回放（含静态资源、含延迟模拟），再看性能瓶颈。只跑“干净的”回放，容易产生虚假的安全感。