nginx 事件驱动架构通过 epoll 监听连接事件实现高并发长连接管理：客户端 keepalive 由定时器控制超时关闭，上游连接池复用并事件监听，tcp 探活与超时协同失效感知，内存预分配与 slab 复用保障零分配高频调度。
Nginx 的事件驱动架构不是靠“多开连接”或“多线程等待”来维持长连接，而是把每个连接当作一个可监听的事件对象，由内核就绪通知、Worker 非阻塞响应，全程无轮询、不阻塞。这种机制让单个 Worker 能稳定管理数万连接，同时精准控制生命周期——空闲时静默休眠，有数据或超时时立刻唤醒，真正实现“有事才动、无事不扰”。
客户端长连接：靠 keepalive + 事件超时精准收放
浏览器默认发 Connection: keep-alive，Nginx 接收到后并不立即关闭 TCP，而是将其注册进 epoll，进入 idle 状态：
- keepalive_timeout 设为 60–75 秒，超时由红黑树定时器事件触发关闭，不占用 CPU 周期
- keepalive_requests 限制单连接最大请求数（如 1000），达到即主动断连，防状态泄漏
- 连接空闲期间不消耗资源；epoll 仅在新请求到达或定时器到期时才唤醒处理
上游连接池：事件调度代替后台线程维护
Nginx 到后端（如 Java 应用）的连接复用，不依赖独立线程保活，而是靠事件循环直接监听空闲连接状态：
- upstream 中配置 keepalive 32，表示每个 worker 最多缓存 32 个空闲连接，全部注册到 epoll 监听可读事件
- 新请求到来时，从池中取出连接 → 注册写事件 → 发送请求 → 若后端未响应，则挂起，转而处理其他就绪事件
- 后端返回响应或主动断连时，事件立即触发 cleanup 或复用逻辑，无需轮询扫描
连接失效感知：TCP 层与应用层事件协同
后端可能静默断连，Nginx 不被动等待错误发生，而是通过多层事件机制提前识别并清理：
- proxy_socket_keepalive on 启用内核 TCP 探活，在空闲时发探测包；收到 RST 或超时后，事件循环立刻标记连接失效
- keepalive_timeout 设为略小于后端实际超时值（例如后端设 90s，Nginx 设 60s），确保在对方关闭前主动释放
- proxy_next_upstream error timeout http_502 让首次复用失败时，事件驱动立即切换连接或重试，不阻塞当前请求
内存与结构复用：零分配支撑高频事件调度
连接复用效率不仅体现在网络层，更依赖底层内存管理的轻量性：
- 所有连接对象（ngx_connection_t）从预分配的连接池中获取，worker 启动时一次性 malloc，运行中只复用不释放
- HTTP 请求上下文、buffer、headers 均来自 slab 分配器，避免频繁 malloc/free 开销
- 整个事件循环中无锁、无同步等待，CPU 缓存友好，适合高吞吐场景
