电商大促需构建具备健康探测、动态权重、会话保持和降级能力的Nginx集群，结合LVS/Keepalived四层分流、upstream动态调度、业务维度流量隔离、缓存降级及系统参数调优。
电商大促期间（如双11、618）的流量具有瞬时性、高并发、地域集中等特点，单台 Nginx 很难承载突发请求，容易成为瓶颈。真正有效的方案不是只靠“多加几台 Nginx”，而是构建具备健康探测、动态权重、会话保持和降级能力的 Nginx 集群，并与上游应用协同设计。
用 DNS + LVS/Keepalived 做第一层入口分流
用户请求最先到达的是公网入口。DNS 轮询精度低、缓存不可控，不建议单独使用。更稳妥的做法是：在 IDC 或云上部署 LVS（DR 模式）或 Keepalived + VIP，作为四层负载均衡器，将流量按连接数或带宽分发到多个 Nginx 接入节点。
- LVS 负责抗住 SYN Flood 和连接洪泛，避免 Nginx 过早进入 TIME_WAIT 或连接耗尽
- Keepalived 提供 VIP 高可用，当某台 Nginx 接入机宕机，VIP 自动漂移到健康节点
- 可结合 GeoDNS 将华南用户导向广州集群、华北用户导向北京集群，缩短 RT
用 upstream 动态组 + health_check 实现 Nginx 节点智能选路
Nginx 集群内部需避免“静态配置陷阱”——即 upstream 写死 IP 后无法感知后端变化。应启用主动健康检查，并支持运行时更新节点状态：
- 使用 nginx-plus 或开源版配合 nginx-module-vts + 自定义脚本，实现 HTTP/HTTPS/TCP 层健康探测
- 配置
max_fails=2 fail_timeout=30s，快速摘除异常 Nginx 接入节点 - 通过
upstream_conf接口或 Consul Template 实现节点增删的热加载，无需 reload
按业务维度做精细化流量隔离与权重调度
大促不是所有请求都同等重要。首页浏览、商品详情、下单支付、库存扣减对稳定性要求差异极大。应在 Nginx 层做语义路由：
- 用
map指令识别 URL 路径或 header（如X-Scene: flashsale），将秒杀请求打到专用 upstream 组 - 为订单服务 upstream 设置
weight=5，为搜索服务设置weight=2，防止搜索拖垮核心链路 - 结合
limit_req对非核心接口（如评论、晒单）限流，保护主流程资源
集成缓存与降级策略，减少穿透压力
Nginx 不只是转发器，更是离用户最近的“缓存网关”和“熔断开关”：
- 对商品页、店铺页等静态化程度高的资源，配置
proxy_cache+Cache-Control头，命中率可达 70%+，大幅降低源站压力 - 利用
error_page 502 503 504 = @fallback，当上游全部不可用时，返回预置的降级 HTML 或 JSON（如“活动火爆，请稍后再试”） - 配合 OpenResty 的 lua_shared_dict，在内存中维护热点商品 ID 的简易计数器，超阈值直接拦截，防止击穿 DB
不复杂但容易忽略：Nginx 集群的性能天花板往往不在配置本身，而在系统参数调优（如 net.core.somaxconn、fs.file-max）、SSL 卸载策略（是否开启 OCSP Stapling、复用 session ticket），以及与上游应用的超时对齐（Nginx 的 proxy_read_timeout 必须 ≥ 应用最大响应时间）。大促前务必做全链路压测，验证集群整体水位和故障转移时效。
