负载均衡压力测试怎么做
公司官网突然打不开了，运维小李一查日志，发现后端三台应用服务器只有一台在扛着流量，另外两台几乎没请求。问题出在哪？很可能是负载均衡器没配好，而上线前又没做压力测试。
别等到用户投诉才想起来查，负载均衡压测得提前做。不是跑个 ab 命令就完事，得模拟真实场景，看分配均不均、节点挂了会不会炸、响应时间能不能忍。
先搞清楚你要测什么
常见的负载均衡策略有轮询、加权轮询、IP哈希、最少连接等。你想验证的是策略有没有生效，还是系统整体扛不扛得住高并发？比如电商大促前，不仅要测单机极限，还得看 LB 能不能把流量合理分下去。
举个例子：你用 Nginx 做反向代理，后端挂了四台 Tomcat。如果压测时发现某一台 CPU 突然飙到 100%，其他三台闲着，那大概率是 IP 哈希导致会话粘滞，或者某台机器配置太弱成了瓶颈。
用工具动手干
最常用的工具是 Apache Bench（ab）和 wrk。ab 简单直接，适合快速验证；wrk 支持脚本，能模拟复杂行为。
比如用 ab 测试 Nginx 的负载分发：
ab -n 10000 -c 100 http://lb-ip/api/user这表示发起 1 万次请求，100 个并发。观察后端各服务器的访问日志，看请求数是否接近平均分配。
如果想测故障转移，手动停掉一台后端服务，再跑一遍压测。正常情况下，LB 应该自动剔除宕机节点，剩下的机器承接全部流量，且整体成功率不能掉太多。
再比如用 wrk，可以写 Lua 脚本模拟登录、浏览商品、下单这一整套流程：
wrk.method = "POST"
wrk.body = '{"username": "test", "pwd": "123456"}'
wrk.headers["Content-Type"] = "application/json"这样测出来的数据更贴近真实业务压力。
关注这几个关键指标
光看“成功了多少次”不够。得盯住每台后端的实际负载、请求延迟分布、错误码比例。比如平均响应时间从 50ms 涨到 800ms，虽然没报错，但用户体验已经崩了。
还有 TPS（每秒事务数）和 QPS（每秒查询数），这两个数据在逐步加压的过程中会先升后平，直到出现拐点。那个拐点就是系统的实际承载上限。
如果压到一半某台后端内存溢出重启，说明负载策略或资源分配有问题，得回过头调权重或优化代码。
别忘了网络层的问题
有时候压测结果不对，不是 LB 配置错了，而是防火墙限速、DNS 缓存没刷新、或者内网带宽被打满了。之前有个案例，压测时 QPS 上不去，最后发现交换机端口只有百兆，根本撑不住千兆流量。
所以压测环境尽量贴近生产，别在本地 Docker 里跑一圈就说没问题。跨机房、跨云厂商的架构更要小心，延迟和抖动会影响健康检查结果。
负载均衡压测不是一次性任务。每次扩容、改配置、升级版本，都得重新跑一遍。把它当成上线前的必过门槛，比事后救火强得多。