后端服务器未分摊流量的最常见原因是负载均衡未生效，如ip hash策略导致请求集中、nlb健康检查失败剔除节点或防火墙拦截探针；应验证直连、检查健康状态、过滤多副本日志并切换轮询策略。
怎么看后端服务器是不是真在分摊流量
压测时最常踩的坑是：明明加了3台后端，但日志里只有1台在打印请求——这说明负载均衡根本没生效，或者策略被“锁死”了。常见原因有：
• 云厂商默认启用了 IP Hash 策略，压测工具用固定源IP（比如单台机器发压），所有请求全打到同一台后端
• NLB 健康检查失败，自动剔除了其他节点，只剩1台在线
• 安全组或防火墙拦截了健康检查探针（如TCP端口不通），导致NLB误判为宕机
实操建议：
• 压测前先用 curl -v http://<nlb-dns>/health</nlb-dns> 手动验证每台后端是否可直连
• 查看NLB控制台的“后端健康状态”，确认全部显示 InService
• 在后端服务日志中按 podName 或 hostname 过滤，确认多副本均有请求记录
• 临时把NLB策略切为 Round Robin 或 Least Connections，排除哈希策略干扰
短连接 vs 长连接：该用哪种压测模式
这不是选“快”还是“慢”的问题，而是测不同能力：
• 测 新建连接数（比如秒杀抢购、API网关首请求）→ 必须用短连接，否则压不出握手瓶颈
• 测 并发连接数（比如游戏长连、WebSocket服务）→ 必须用长连接，短连接会反复建连，掩盖真实并发承载力
容易忽略的细节：
• 短连接压测时，客户端本机端口耗尽极快（Linux默认 net.ipv4.ip_local_port_range = 32768 65535，最多约3万连接），需提前调大或分布式发起
• 长连接压测时，别只看“连接数”，要配心跳（如每30秒发一次 PING），否则中间设备（NAT/防火墙）可能主动断连
• 工具参数示例：
– iperf3 -c <nlb-ip> -t 60 -P 100</nlb-ip>（100并发TCP流，测带宽+连接稳定性）
– ethr -c <nlb-ip> -p tcp -n 50000 -i 30</nlb-ip>（5万长连接，每30秒保活）
为什么成功率突然掉到80%，但平均响应时间才涨了2ms
这是典型“超时掩蔽”现象：压测工具默认超时设得太长（比如30秒），失败请求拖长了整体统计，掩盖了真实拐点。实际可能在并发到某阈值时，大量请求已卡在连接建立或NLB转发队列里，只是还没超时。
正确做法：
• 把压测工具的超时统一设为 5s 或更短（jmeter 中设置 HTTP Request Defaults → Timeout → Response）
• 关注 连接建立成功率 和 p99时延，而非平均值——p99从10ms跳到200ms，往往比平均值涨5ms更有预警价值
• 同时抓NLB侧指标：如 ActiveFlowCount（活跃连接数）、RejectedConnectionCount（拒绝连接数），这两个比后端CPU更能定位NLB自身瓶颈
工具选错，压的根本不是NLB而是你的本地网卡
用 jmeter 单机压10万QPS，大概率压不上去，因为JVM和本地网络栈先扛不住；用 locust 脚本跑HTTP，如果没开连接池复用，实际测的是TCP握手性能而非业务吞吐。
按场景选工具更靠谱：
• 测NLB底层能力（吞吐/连接/丢包）→ 用 iperf3（TCP/UDP带宽）、ethr（连接建模）、tsung（千万级并发模拟）
• 测业务链路（含DNS解析、SSL握手、后端处理）→ 用 jmeter 或 locust，但必须分布式部署（至少3台压测机）
• 模拟真实用户行为（登录→下单→支付）→ 用 locust 写Python脚本，注意加 requests.Session() 复用连接，避免重复建连干扰结果
真正难的不是跑出数字，而是让每个数字都对应一个可归因的组件：是NLB的连接跟踪表满了？是后端某台机器磁盘IO卡住？还是压测机自己丢包？这些得靠交叉比对指标——比如当 RejectedConnectionCount 上升，同时 ClientResetCount 也飙升，基本能锁定是NLB侧资源耗尽，而不是后端挂了。
