Nginx集群应对突发流量需三层协同：连接层调大内核参数与backlog值确保请求接入；分发层按场景动态选用least_conn、ip_hash等算法并支持运行时切换；后端层实施连接、请求、响应三层过载防护，并通过LVS分流、健康检查、流量隔离与缓存降级强化集群弹性。
Nginx 集群应对突发流量，关键不在“平均分发”，而在“按需调度+弹性缓冲+快速止损”。单靠加机器或调高 worker 数量解决不了根本问题，必须从连接接入、分发策略、后端承载三层协同发力。
连接层：先让请求进得来
突发流量最先卡在 TCP 建连环节。若系统来不及 accept，SYN 包会被内核直接丢弃，客户端看到 Connection refused，日志里却查不到痕迹。
- 统一调大三个参数：
net.core.somaxconn、net.ipv4.tcp_max_syn_backlog、ulimit -n，建议都设为 65535 或更高 - Nginx 的
listen指令必须显式带backlog=65535，例如：listen 80 backlog=65535;，否则默认值（通常 511）极易成为瓶颈 - 验证方式：压测时执行
ss -lnt，观察对应端口的Recv-Q是否接近你设置的 backlog 值
分发层：按场景动态选算法，不 reload 切换
没有万能算法，轮询在洪峰下容易打爆单点。应根据业务特征匹配并支持运行时切换：
- 短连接洪峰（如秒杀、抢券）→ 用
least_conn：新请求总发给当前活跃连接最少的后端，抗瞬时冲击 - 长连接会话（如 WebSocket、实时课堂）→ 用
ip_hash+ 主动健康检查：保障会话粘性，同时自动隔离异常节点 - 后端能力不均（新老机器混布）→ 配
weight：新机器设weight=5，旧机器设weight=2，按真实处理力分摊 - 延迟敏感接口（如搜索、推荐）→ 结合
nginx-upstream-check-module，基于响应时间动态调权，慢节点自动降权 - 实现秒级切换：定义多个 upstream（如
backend_least、backend_hash），再用map提取请求头或 cookie 控制路由，proxy_pass http://$target_upstream即可生效
后端层：三层过载防护，不止于限流
限流只是第一道闸，真实过载常始于连接堆积、请求积压和响应阻塞：
- 连接层防护：
limit_conn_zone $binary_remote_addr zone=conn_perip:10m; limit_conn conn_perip 10;，防 Slowloris 类慢速攻击 - 请求层分流：对非核心路径（如评论、埋点）单独限流；运维接口（
/health、/metrics）严格限速（如rate=1r/s） - 响应层容错：配置
proxy_next_upstream error timeout http_500 http_502 http_503 http_504+proxy_next_upstream_tries 2，后端短暂不可用时自动重试并摘除，切断雪崩链路
集群级协同：避免单点瓶颈，强化整体弹性
- 入口层用 LVS/Keepalived 做四层分流：抗 SYN Flood，提供 VIP 高可用，把压力分散到多台 Nginx 接入节点
- Nginx 接入层启用主动健康检查：
health_check interval=3 fails=1 passes=1;，快速发现故障节点；搭配backup服务器兜底 - 按业务维度隔离流量：用
location或map将秒杀、下单、搜索等请求路由到不同 upstream，防止非核心链路拖垮主流程 - 在 Nginx 层集成缓存与降级：
proxy_cache缓存商品页等静态资源；error_page 502 503 504 = @fallback返回预置降级页，避免请求穿透
不复杂但容易忽略：所有这些配置必须联动验证。比如调大了 backlog，但没同步改 ulimit 和 somaxconn，等于白调；开了 least_conn，却没配健康检查，异常节点仍会持续收请求。
