单机nginx百万并发靠精准配置与内核协同；分布式集群核心是解决状态一致性、流量可溯性、故障自动收敛三件事。
单机 Nginx 能扛住百万并发，靠的不是堆硬件，而是精准配置与内核协同；真正走向分布式集群，核心不在多加几台 Nginx，而在解决状态一致性、流量可溯性和故障自动收敛这三件事。
单机极限压测：不只是调高 worker_connections
很多人以为把 worker_connections 改到 10 万就等于支持百万连接——其实漏掉了关键前提：
- Linux 内核参数必须同步调优：
net.core.somaxconn、net.ipv4.ip_local_port_range、fs.file-max需匹配连接数规模 - Nginx 必须运行在
epoll模式（Linux 默认），且禁用accept_mutex（高并发下反而成瓶颈） - 静态资源务必启用
sendfile on和tcp_nopush on，减少用户态拷贝 - 超时设置要分层：短连接设
keepalive_timeout 15s，长连接（如 WebSocket）需单独 upstream 配置心跳保活
反向代理集群：从“能转发”到“懂业务”
单纯用多台 Nginx 做轮询，只是横向扩容；真正提升可用性，得让 Nginx 知道请求背后是谁、要什么、能不能切：
- 按用户标识（如 cookie 中的
uid）做一致性哈希，保证同一用户始终落在同一后端，避免 session 丢失 - 对关键接口（如支付回调）配置
proxy_next_upstream error timeout http_502，自动重试非幂等失败 - 用
sticky cookie或ip_hash仅适用于小规模；中大型系统推荐基于 Redis 的会话路由表，由 Lua 脚本动态查表转发 - 所有 upstream 节点必须暴露健康检查端点，Nginx 配置
health_check interval=3 fails=2 passes=2实现秒级故障摘除
分布式 Nginx 管理：配置即代码 + 变更可灰度
当 Nginx 节点超过 10 台，手工改配置、scp 分发、逐台 reload 已不可持续。此时需引入三层管控：
- 配置中心化：用 Consul 或 Nacos 存储
upstream列表和路由规则，Nginx 通过 OpenResty 的resty.http定期拉取更新 - 变更原子化：每次发布生成唯一版本号，旧配置保留 24 小时，支持一键回滚
- 灰度自动化：新规则先推给 5% 流量节点，结合 Prometheus 监控 5xx 率与延迟 P95，达标后再全量
- 日志统一归集：每条 access_log 加入
$request_id和$upstream_addr，便于全链路追踪
跨机房与多云场景：Nginx 不再是终点，而是入口网关
单一区域部署 Nginx 集群已无法满足容灾与低延时要求。这时它要升级为全局流量调度器：
- 接入 DNS 负载均衡（如阿里云云解析 DNS 的 GSLB），按地域、运营商、延迟返回最优 IP
- 各机房内部署独立 Nginx 集群，对外统一 VIP；内部用 BGP+ECMP 实现多活流量分担
- 关键服务（如登录、下单）启用跨机房双写或最终一致性同步，Nginx 层配合
mirror指令做流量镜像验证新集群 - 边缘节点（如 CDN 回源层）部署轻量 OpenResty，承担 WAF、AB 测试、灰度标透传等前置逻辑，减轻核心集群压力
