Nginx利用epoll事件驱动实现高效限流Limit

limit_req依托epoll事件驱动与共享内存实现高效限流：请求在preaccess阶段内存中查写状态，零系统调用；合理配置key、zone大小、burst及nodelay可优化性能；避免复杂key与冗余zone以防止开销上升。

nginx利用epoll事件驱动实现高效限流limit_req

Nginx 通过 epoll 事件驱动模型高效处理大量并发连接，而 limit_req 模块正是依托这一机制，在不显著增加 CPU 开销的前提下，实现精准、低延迟的请求速率限制。

limit_req 并非靠定时轮询或线程阻塞实现限流，而是利用 Nginx 的事件驱动架构：

Nginx 主循环基于 epoll_wait() 监听 socket 事件，所有请求到达都以事件形式被快速捕获；
限流状态（如每个 key 的最近请求时间、当前计数）存放在 shared memory zone 中，所有 worker 进程可无锁读写（通过原子操作和 slab 分配优化）；
每次请求在 NGX_HTTP_PREACCESS_PHASE 阶段即时查表+更新状态，全程在内存中完成，无系统调用或磁盘 I/O。

合理配置能进一步释放 epoll + 共享内存的效率优势：

limit_req_zone $binary_remote_addr zone=ip_limit:10m rate=10r/s：使用 $binary_remote_addr 减少字符串哈希开销；10m 区域大小需预估 key 数量（约每 64 字节存一个 key），避免频繁淘汰；
limit_req zone=ip_limit burst=20 nodelay：启用 burst 提供平滑缓冲；若去 nodelay，则排队等待会引入微小延迟，但更公平；加 nodelay 则突发请求立即响应或拒绝，适合对延迟敏感场景；
配合 multi_accept on 和 accept_mutex off（高并发时），让单次 epoll_wait 触发后尽可能多地 accept 连接，减少事件循环次数。

即使有 epoll，错误用法仍会导致限流变重或失效：

勿用复杂变量做 key（如 $request_uri 或带参数的 URL），哈希与比较成本高，且易触发共享内存满；优先选固定长度字段如 $binary_remote_addr 或 $server_name；
不要为每个 location 单独建大 zone，应复用 zone，按需调整 burst 和 rate 参数；
日志中开启 $limit 变量（需编译时含 --with-http_realip_module 等支持），便于验证是否真正在限流路径上执行，而非因配置未生效绕过。

限流本身不是瓶颈，关键在于让 Nginx 在 epoll 事件流中以最轻量方式完成判断——共享内存查写、原子操作、零拷贝 key 处理，这才是 limit_req 在万级 QPS 下依然稳定的原因。