multi_accept 是百万级瞬时并发下连接吞吐的关键环节，需与缓存机制协同：它使 worker 在一次事件循环中批量 accept 内核 backlog 中已完成三次握手的连接，减少唤醒与上下文切换，配合 use epoll 和 high worker_connections 才生效，实测吞吐提升 20%–30%。
multi_accept 不是“锦上添花”的可选项，而是百万级瞬时并发下连接吞吐的临门一脚；它必须和缓存机制协同设计——前者决定连接能多快被收进来，后者决定进来之后能不能不压垮后端。
multi_accept 的真实作用与启用逻辑
multi_accept on 的本质，是一次事件循环中尽可能多地调用 accept()，把内核 backlog 队列里积攒的已完成三次握手的连接一次性收完。这直接减少 epoll_wait 唤醒次数和上下文切换开销，在突发流量涌入时尤为关键。
- 默认关闭时，每个事件循环只 accept 一个连接，高并发下容易形成“连接堆积→唤醒延迟→响应变慢”的恶性循环
- 开启后实测吞吐提升 20%–30%，尤其在短连接密集型场景（如大促首页静态资源请求、API健康探针）效果显著
- 需配合 use epoll 和 worker_connections ≥ 65535 使用，否则无法发挥价值
- 注意：若后端是长连接且建连频次低（如 WebSocket 网关），反而可考虑关闭以降低锁竞争
缓存机制必须分层落地，不能只靠 Redis
瞬时百万并发下，90% 以上的请求必须在 Nginx 层或本地就拦截掉，否则再快的 multi_accept 也救不了后端雪崩。
- 静态资源直出 + sendfile：HTML/CSS/JS/图片等走 Nginx 文件系统直出，启用 sendfile on 和 tcp_nopush，绕过用户态拷贝，单机轻松扛 50 万 QPS
- 本地缓存兜底：对热点接口（如商品详情页），用 nginx 模块如 ngx_http_proxy_cache 或 OpenResty 的 lrucache 做毫秒级本地缓存，避免每次穿透到上游
- Redis 缓存做主存+布隆过滤器防穿透：对 key 存在性不确定的查询，先过布隆过滤器；命中再查 Redis；未命中不查 DB，直接返回空或降级数据
- 缓存失效策略要平滑：避免大量 key 同时过期引发“缓存雪崩”，采用随机 TTL 或后台异步刷新
multi_accept 与缓存协同的关键配置组合
单独调参没用，真正起效的是几个参数的联动关系：
- events 块中必须同时设置：multi_accept on;、use epoll;、worker_connections 100000;
- 全局块声明：worker_rlimit_nofile 1000000;（确保进程级 fd 上限 ≥ worker × connections）
- 系统级配套：fs.file-max ≥ 1300000，ulimit -n 1000000，否则 accept 失败报 “Too many open files”
- proxy 缓存相关：proxy_cache_valid 200 304 10s;（短 TTL 配合高频刷新）、proxy_cache_use_stale error timeout http_502;（异常时仍可用旧缓存）
别忘了连接生命周期管理
multi_accept 收得快，但连接不及时释放照样拖垮系统。瞬时并发不是看峰值连接数，而是看连接周转效率：
- 对上游服务启用 keepalive 32（保持 32 个空闲长连接），大幅降低后端建连压力
- 客户端侧设置 keepalive_timeout 15; keepalive_requests 100; 防止长连接僵死占用资源
- 关闭 access_log 或改用 buffer+flush 异步写入，避免 I/O 成为瓶颈
- 动态接口务必配合全链路限流（Nginx limit_req + API 网关用户级限流 + 服务内 Sentinel 线程池隔离）
