秒杀场景下Nginx upstream连接池需协同配置三要素：连接复用真生效（keepalive 32～64、HTTP/1.1、keepalive_requests/timeout合理设置）、负载调度动态避热（least_conn+max_conns+queue）、超时限流分层兜底（系统级调参、IP限连、核心路径短超时），并实测验证复用效果。
秒杀场景下，Nginx upstream 连接池不是“开个 keepalive 就行”，而是要让每个环节都扛住短连接洪峰、避免后端雪崩。关键在三点：连接复用要真生效、负载调度要动态避热、超时与限流要分层兜底。
连接池参数必须协同生效，单配 keepalive 无效
秒杀请求密集、生命周期短，若 upstream 长连接不真正复用，每秒数千请求就会触发等量 TCP 建连，压垮后端并堆积 TIME_WAIT。
- upstream 块中设 keepalive 32～64（非全局值，是每个 worker 对每台后端的空闲连接上限）；按后端单实例稳定并发 × 0.6 ÷ worker 数估算，例如 Tomcat maxConnections=200、4 个 worker → 推荐 32
- location 中必须写 proxy_http_version 1.1 和 proxy_set_header Connection ""，否则 Nginx 默认发 HTTP/1.0 请求，直接绕过复用逻辑
- 配套设 keepalive_requests 500～1000（避免单连接承载过多请求导致延迟毛刺），keepalive_timeout 比后端 idle timeout 小 5～10 秒（如 Tomcat connectionTimeout=60s，此处设 45s）
负载算法切 least_conn，防单点打满
轮询或加权轮询在秒杀瞬间极易造成流量倾斜——某台后端连接数飙升至极限，其余机器尚有余力，但新请求仍被继续打过去。
- upstream 块内明确声明 least_conn，Nginx 会把新请求优先转发给当前 Active connections 最少 的后端节点
- 搭配 max_conns=200（略低于后端 maxConnections），防止突发流量击穿单机连接上限；建议同时启用 queue=10 timeout=5s（Nginx 1.23.3+），超额请求暂存队列而非直接 502
- 禁用 ip_hash（会话粘滞不适用秒杀无状态请求），避免用户集中压向某台机器
连接与请求双层防护，避免连锁失败
秒杀冲击最先卡在连接建立和请求排队环节，需从系统级到 Nginx 级同步加固。
- 系统层调高 net.core.somaxconn 和 net.ipv4.tcp_max_syn_backlog 至 65535，并在 listen 指令中显式加 backlog=65535，防 SYN 包被内核丢弃
- Nginx 层启用 limit_conn_zone $binary_remote_addr zone=conn_perip:10m + limit_conn conn_perip 10，限制单 IP 并发连接数，防恶意刷量挤占资源
- 对秒杀核心路径（如 /api/seckill）单独配置 proxy_connect_timeout 2s、proxy_read_timeout 8s，超时快速失败，不阻塞连接复用
验证是否真正起效，不能只看配置
改完配置后必须实测确认连接复用状态，否则形同虚设。
- 压测中执行 ss -tan | grep :8080 | grep ESTAB | wc -l，观察连接数是否稳定在 worker 数 × keepalive 值 附近（如 4 worker × 32 = 128），而非随 QPS 持续线性增长
- 检查后端响应头是否含 Connection: keep-alive；若返回 close 或缺失，Nginx 不会回收该连接进池
- 开启 stub_status，访问 /nginx_status 查看各 upstream server 的 Active connections 分布，确认 least_conn 是否真正均衡了连接负载
