3. 双引擎架构概述：本地引擎 vs 分布式引擎
JMeter 压测引擎的部署模式直接决定了容量上限、资源隔离策略和运维复杂度。在巡检脚本编排场景中，本地引擎与分布式引擎并非互斥，而是根据被测系统容量、压测节点资源、网络拓扑等因素进行选型组合。本节从架构原理、适用场景、优缺点三个维度进行对比。
3.1 本地引擎架构
本地引擎指所有 JMeter 组件（线程组、取样器、监听器）运行在同一台物理机或容器内，由单一 JVM 进程驱动。其核心特征是进程内全同步——控制、调度、采样、聚合全部在同一个地址空间完成。
架构要点：单 JVM 进程 → 无网络序列化开销 → 毫秒级时间精度 → 适合低并发、高精度场景。
3.2 分布式引擎架构
分布式引擎将控制节点（Controller）与执行节点（Agent/Worker）分离，通过 JMeter 原生 RMI 协议或第三方消息中间件进行任务分发与结果回传。每个 Worker 独立运行 JVM 进程，可部署在不同物理机、容器或云实例上。
关键区别：分布式架构引入了网络 I/O、序列化/反序列化、时钟同步等额外开销，但换来了近乎线性的容量扩展能力。
3.3 核心对比维度
| 对比维度 | 本地引擎 | 分布式引擎 |
|---|---|---|
| 部署复杂度 | 零部署，单机启动即可 | 需配置 RMI 端口、防火墙、密钥、Agent 启动脚本 |
| 最大并发用户数 | 受限于单机 CPU/内存，通常 ≤ 2000 线程 | 可扩展至数万线程（取决于 Worker 数量） |
| 时间精度 | 毫秒级，无网络抖动 | 受网络延迟影响，通常 1-5ms 偏差 |
| 资源隔离 | 共享 JVM 堆，GC 影响全局 | Worker 独立 JVM，GC 互不影响 |
| 结果聚合 | 实时本地聚合，无数据丢失 | 需网络回传，可能丢包或延迟 |
| 故障域 | 单点故障，进程崩溃即终止 | 单 Worker 故障不影响其他 Worker |
| 脚本同步 | 无需同步 | 需确保所有 Worker 脚本版本一致 |
3.4 适用场景与选型建议
选型口诀：低并发、高精度、快速验证用本地；高并发、长周期、多节点用分布式。
本地引擎适用场景
- 接口功能验证：单接口 50-200 并发，验证响应时间、状态码、断言逻辑。
- 巡检脚本调试：开发阶段快速迭代，无需搭建分布式环境。
- 低容量基线测试：被测系统预期 TPS < 500，单机足以模拟。
- 时间敏感场景：需要精确到毫秒级的请求间隔控制。
分布式引擎适用场景
- 容量压测：目标 TPS > 2000，单机无法模拟真实负载。
- 多地域压测：Worker 部署在不同机房，模拟用户分布。
- 长周期巡检：7×24 小时压测，单机可能因 GC 或内存泄漏中断。
- 资源隔离要求：避免多个压测任务互相干扰。
常见误区：不要认为分布式一定比本地好。对于 < 500 并发的小型巡检，分布式引入的网络开销反而会降低结果精度，且运维成本远高于本地引擎。
3.5 混合架构实践
在大型压测平台中，通常采用本地 + 分布式混合架构：
- 脚本编排阶段：使用本地引擎快速验证脚本正确性。
- 预压测阶段：单 Worker 本地运行，确认基线指标。
- 正式压测阶段：切换至分布式模式，多 Worker 并发施压。
- 结果对比：对比本地与分布式结果，识别网络偏差。
# 混合架构典型启动流程
# 1. 本地验证
jmeter -n -t script.jmx -l local_result.jtl
# 2. 分布式启动（假设 3 个 Worker）
jmeter -n -t script.jmx -R 192.168.1.10:1099,192.168.1.11:1099,192.168.1.12:1099 \
-l distributed_result.jtl通过上述对比可以看出，双引擎架构的核心差异在于资源隔离粒度与网络开销之间的权衡。在巡检脚本编排选型时，应优先根据目标并发量、时间精度要求和运维能力选择引擎模式，而非盲目追求分布式。