JMeter Retrier 插件：让失败请求自动重试，告别脚本繁琐循环
解决 JMeter 原生不支持重试的痛点，一行配置轻松实现智能重试
一、为什么需要重试插件？
在用 JMeter 做接口测试或性能压测时，经常会遇到因网络抖动、服务限流（HTTP 429）、临时错误等导致的请求失败。JMeter 本身没有提供失败重试机制，要么忽略错误继续执行，要么直接停止线程，很难优雅地处理这种"可恢复"的异常。
虽然可以通过 While Controller + 变量手动实现重试逻辑，但配置繁琐，尤其当业务流程中有多个需要重试的步骤时，脚本会变得复杂难维护。
JMeter Retrier 插件应运而生 ------ 只需添加一个后置处理器，就能让任意取样器具备智能重试能力。
二、插件简介
- 项目地址 ：tilln/jmeter-retrier
- 最新版本：1.0（2022-05-27）
- JMeter 要求：5.0 及以上
- 核心功能：对失败的取样器自动重试，支持多种退避策略、条件匹配、Retry-After 响应头等
三、安装方法
通过 Plugins Manager 安装
- 确保你已经安装了 JMeter Plugins Manager（将
plugins-manager.jar放入lib/ext并重启 JMeter）。 - 打开 JMeter，点击菜单栏
Options→Plugins Manager。 - 切换到 Available Plugins 选项卡，在搜索框输入
Sample Retrier。 - 勾选插件，点击右下角 Apply Changes and Restart JMeter 完成安装。
（实际界面中搜索 "Sample Retrier" 即可）
验证安装成功 ：在测试计划中添加取样器（如 HTTP 请求），右键
添加 → 后置处理器，能看到Retry Post-Processor即表示成功。
四、基础使用教程
4.1 快速上手：让 HTTP 请求失败后重试 3 次
- 创建测试计划 ：添加
线程组→ 添加HTTP 请求（比如请求一个可能返回 429 的接口）。 - 添加重试处理器 ：右键点击该 HTTP 请求 →
添加→后置处理器→Retry Post-Processor。 - 配置关键参数：
| 参数 | 值 | 说明 |
|---|---|---|
Max Number of Retries |
3 | 最多重试 3 次 |
Response Part |
None | 默认只要请求失败（响应码非 2xx/3xx）就重试 |
Pause (milliseconds) |
1000 | 每次重试前等待 1 秒 |
Backoff |
None | 固定延迟，不递增 |
配置界面如下图所示：
运行后，如果原始请求失败，你会看到 子结果 中依次出现 xxx-retry 1、xxx-retry 2... 直到成功或达到最大重试次数。
重试条件（Response Part）
None：只要请求失败（超时、连接异常、任何非 2xx）就重试
Response code：按状态码重试
Data：响应内容包含错误文本（如 "服务不可用"）
Headers：响应头包含错误信息
Message：响应消息（如 "Internal Server Error"）
4.2 进阶配置：条件重试 + 智能延迟
重试条件（Response Part）
None：只要请求失败（超时、连接异常、任何非 2xx）就重试
Response code：按状态码重试
Response Data：响应内容包含错误文本（如 "服务不可用"）
Response Headers：响应头包含错误信息
Response Message：响应消息（如 "Internal Server Error"）
示例选择根据响应内容（Response Data）判断是否重试
有时请求成功（HTTP 200）但业务返回错误码（如 {"code":500}），此时需要重试。
Response Part：选择Response DataError Pattern：填入"code":500（正则表达式）
这样，只有当响应数据中包含 "code":500 时才会触发重试。
使用退避策略避免加重服务器压力（Backoff）
| Backoff 策略 | 延迟计算公式（Pause=100ms） | 适用场景 |
|---|---|---|
| None | 100, 100, 100... | 快速重试，对服务器影响小 |
| Linear | 100, 200, 300... | 逐步退让，缓解瞬时压力 |
| Polynomial | 100, 400, 900... | 快速降低重试频率 |
| Exponential | 100, 200, 400, 800... | 经典退避，适合限流场景 |
可通过 JMeter 属性
jmeter.retrier.backoffMultiplier调整指数/多项式的底数（默认 2）。
配合 Jitter 避免惊群效应
设置 Jitter Factor = 0.1，会在计算出的延迟上增加 ±10% 的随机波动，防止多个线程同时重试造成二次拥堵。
尊重服务端返回的 Retry-After 头
勾选 Respect "Retry-After" 后，如果服务器响应头包含 Retry-After: 10（单位秒），插件会等待 10 秒后再重试（若同时设置了 Pause，则取两者较大值）。
五、结果如何呈现？
- 原始失败请求和每一次重试都会作为 子结果 显示，标签格式为
原标签-retry N。 - 最终的主结果（
原标签-retry）包含最后一次尝试的请求/响应数据、所有尝试的总字节数、总响应时间（不含暂停）。
这样既能看到每次重试的细节，也能用最终结果做断言，非常方便。
六、⚠️ 重要限制（务必了解）
由于 JMeter 线程执行机制的限制，使用本插件时请注意：
- 预处理器（Pre-Processors）、定时器（Timers）只会在首次尝试前执行一次，不会在每次重试前重新执行。
- 断言（Assertions）和其他后置处理器（Post-Processors）只会在最终尝试后执行一次，不会对每次重试分别断言。
- 连接时间、延迟时间、空闲时间不会累积，主结果中仅包含最后一次尝试的耗时（总响应时间是累加值）。
这意味着：如果你的请求依赖动态参数（如每次重试前需要重新获取 token），则需要手动处理（比如将获取 token 的取样器放在循环外部，或者使用 While Controller 自己实现重试）。
七、常见问题 FAQ
Q1：能和其他后置处理器（如 JSON Extractor）一起用吗？
A：可以，但请注意顺序。放在 Retry Post-Processor 之前 的后置处理器会在重试前执行（仅一次），放在之后的会在重试结束后执行（仅一次）。如果想每次重试都提取变量，不适用。
Q2：能重试 JDBC Request 或 JSR223 Sampler 吗？
A：可以，只要是 JMeter 取样器，且能通过 Result status（成功/失败）或响应内容判断是否需要重试即可。
Q3：如何修改重试子结果的标签后缀？
A：设置 JMeter 属性 jmeter.retrier.sampleLabelSuffix，例如 -retryAgain，默认为 -retry。
Q4：无限重试会不会导致死循环？
A：将 Max Number of Retries 设为负数即可无限重试，但建议配合 Pause 和退避策略，并确保有成功退出条件，否则会一直运行。
八、总结
| 优点 | 缺点/限制 |
|---|---|
| ✅ 配置简单，无需编程 | ❌ 预处理器/定时器等不会在重试时重新执行 |
| ✅ 支持多种退避策略和 Jitter | ❌ 断言仅对最终结果生效 |
| ✅ 可基于响应内容/状态码灵活匹配 | ❌ 项目已两年未更新（但功能稳定） |
| ✅ 结果清晰，子结果详细 | ❌ 仅支持 JMeter 5.0+ |
如果你的 JMeter 脚本经常因为临时性故障而失败，JMeter Retrier 绝对是你的救星。它大幅降低了实现重试逻辑的复杂度，让脚本更加简洁可靠。
赶快试试吧！安装 Plugins Manager 后搜索 Sample Retrier 即可一键安装。
欢迎在评论区留言讨论使用心得或踩坑经验。如果觉得文章对你有帮助，请点赞收藏支持一下～