Limit_req模块实现的是带延迟补偿的漏桶算法变种，通过共享内存中记录时间戳与动态计算超额量（excess）来离散化模拟漏桶，核心依赖ngx_http_limit_req_lookup()三次判定及红黑树惰性淘汰机制。
Limit_req模块在Nginx中实现的是**经典漏桶（Leaky Bucket）算法的变种**，但不是严格意义上的“每秒匀速漏出”，而是以“固定时间窗口+令牌桶思想融合”的方式做请求速率控制。理解它的关键不在于找一个标准漏桶公式，而在于读懂其源码中两个核心结构：ngx_http_limit_req_shctx_t（共享内存上下文）和ngx_http_limit_req_node_t（每个key对应的限流节点），以及核心函数ngx_http_limit_req_lookup()的判定逻辑。
漏桶在Limit_req中的实际表现形式
Nginx并不维护一个持续滴水的“桶”，而是为每个限流key（如$binary_remote_addr）记录上一次成功请求的时间戳（node->last）和当前“剩余容量”（隐含在时间差计算中）。当新请求到达时，它会：
- 根据当前时间
tp->msec和node->last计算已过去的时间 Δt（毫秒） - 按配置的速率（如
rate=1r/s→ 每1000ms允许1个），算出这段时间“本该漏掉/释放”的请求数：Δt × rate / 1000 - 用这个值去“恢复”可用配额（即等效于桶中重新流入的令牌），再判断是否足够接纳当前请求
这本质上是**离散化模拟漏桶**：没有连续水流，只有每次请求来临时，根据时间差批量“补漏”，再扣减1个单位。因此它更接近“带延迟补偿的漏桶”，而非Redis-cell那种精确微秒级漏出的实现。
看懂 ngx_http_limit_req_lookup() 的三次判定
该函数是限流决策的核心，返回值决定是否拒绝（NGX_BUSY）或放行（NGX_OK）。它内部依次检查：
-
是否存在已有节点：若无，则尝试插入；若共享内存满（
shpool->nalloc == shpool->max），直接返回NGX_BUSY -
是否超出burst容量：即使“漏”出了额度，当前请求数也不能超过
limit_req.burst。这里用node->excess累计超额量，若excess > limit * burst就拒绝 -
是否需延迟处理：若
excess > limit（即超了基础速率但没超burst），则进入延迟队列，等待excess / limit * 1000毫秒后重试（对应limit_req.nodelay是否开启）
注意：excess 并非独立存储，而是每次调用时由 excess = node->excess - (Δt × rate / 1000) 动态衰减后再+1得到，体现“漏”与“注”的平衡。
共享内存中如何保证多进程一致性
所有worker进程共用一块共享内存（limit_req_zone ... zone=name:10m），节点增删改都通过 ngx_shmtx_lock(&shpool->mutex) 加锁。重点看两个细节：
- 节点查找用红黑树（
shpool->rbtree），key是经过MD5哈希后的二进制地址（$binary_remote_addr），避免字符串比较开销 - 过期清理不依赖定时器，而是在每次查找失败、尝试插入新节点时，扫描红黑树最左节点（最小时间戳），若
node->last + expire 则复用其内存——这是典型的“惰性淘汰”
这也解释了为什么高并发下偶尔出现“瞬时超限”：多个进程同时查不到节点、又几乎同时申请新节点，可能短暂突破zone大小限制，直到下次惰性清理。
动手验证：加日志看清漏桶怎么“漏”
想真正看清算法行为，可在 src/http/modules/ngx_http_limit_req_module.c 的 ngx_http_limit_req_lookup() 开头添加：
ngx_log_debug2(NGX_LOG_DEBUG_HTTP, r->connection->log, 0,
"limit_req: key='%V', last=%M", &key, node ? node->last : 0);
配合配置：
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
limit_req zone=one burst=3 nodelay;
用 ab -n 10 -c 2 http://localhost/ 测试，观察日志中 last 值的变化节奏：你会发现它并非均匀递增1000ms，而是随请求密集程度动态“跳变”，印证了“按需补漏”的设计本质。
