📌 一句话概括
单台JMeter压测机的并发能力有限（通常2000-5000线程），分布式架构通过Master-Slave模式将多台机器组成压测集群，是银行业大规模压测（万级TPS以上）的基础设施。
💡 分布式压测架构
Master-Slave架构
JMeter分布式由一个Master节点 + N个Slave节点组成：
- Master（控制端）：管理测试计划、分发脚本、收集结果、生成报告。不执行压测，资源消耗低
- Slave（执行端）：接收Master下发的脚本片段，独立执行压测，将结果回传Master
集群部署要点
- Slave节点配置统一：所有Slave的JMeter版本、插件、Java版本必须一致
- 网络要求：Master与Slave间需低延迟网络，Slave与被测系统间需高带宽
- 时钟同步：所有节点需NTP时间同步，确保结果时间戳一致
- 资源监控：除监控被测系统外，还需监控Slave节点的CPU和内存——压测机本身过载会污染测试结果
总并发量计算
总并发线程数 = Slave数量 × 单Slave线程数。例如：5台Slave，每台1000线程，总并发=5000。实际吞吐量不线性增长——当Slave数量超过8-10台时，Master收集结果的网络开销可能成为瓶颈。
🔧 Agent管理与自动化
Slave Agent部署
每台Slave需运行jmeter-server进程（Linux）或jmeter-server.bat（Windows）。生产级部署建议：
- 用systemd管理jmeter-server进程，设置自动重启
- Slave节点配置独立的内网IP，与被测系统在同一网段以减少网络延迟
- 配置rmi.keystore实现Master-Slave间的SSL加密通信
容器化部署方案
将JMeter Slave打包为Docker镜像，配合Kubernets实现弹性压测集群——需要时快速扩容Slave节点数，压测完成后回收资源。适合需要大规模并发（>10000线程）的场景。
🔍 测试实战
1. 分布式压测环境搭建
操作：准备3-5台Slave（建议4C/8G以上），确保Master能SSH免密登录所有Slave。修改jmeter.properties中的remote_hosts配置，通过jmeter -n -t script.jmx -R slave1,slave2,slave3 -l result.jtl启动分布式压测。
2. 分布式压测结果一致性验证
操作：先用单机跑小并发建立基线，再用3台Slave各分配1/3并发跑相同场景，对比总TPS是否接近单机基线的3倍。偏差>15%说明存在协同瓶颈。
⚠️ 常见坑点
- Slave配置不一致——插件版本或JVM参数不同，各节点产生的结果不可比
- Master网络瓶颈——Slave超过10台后结果回传可能导致Master网卡打满
- 时钟不同步——各Slave返回的时间戳偏差导致报告中的TPS曲线出现毛刺
- 忽略了Slave资源消耗——压测机CPU使用率超过80%会影响施压稳定性
📖 延伸阅读
- Apache JMeter 官方文档 - Remote Testing
- JMeter Docker 镜像（justb4/jmeter）