漏桶

nginx 请求限流使用漏桶方法，依据配置速率计算超额请求。burst 决定可以接受多少超额，nodelay 和 delay 则影响已经被接受的超额请求何时继续处理。这里涉及准入与调度，并不是所有超过名义速率的请求都会失败，也不是直接测量应用里有多少并发工作。理解这几个不同维度，才能解释一次突发里为何同时出现成功、等待和拒绝。 坏掉的样子 把 nodelay 解释成“立即丢弃超额”，正好说反了它的作用。在突发额度以内，它允许超额请求不经过通常的延迟，直接继续处理；超过额度才拒绝。已经接受的突发仍消耗需要随时间恢复的容量。后端很快完成，并不会让下一批突发自动获得全新额度，因此不能把 nodelay 理解成只管单次批次、不累计速率债务。 被延迟的请求也不会自动变成一串 503。突发范围内获准等待的请求，可以在等待之后得到成功应用响应；超过配置额度才会按所选状态拒绝。客户端自己的截止时间可能在等待中到期，所以服务器能接受的排队，不一定满足客户端延迟契约。讨论结果时应区分服务端拒绝、获准等待和客户端主动超时。 配置语法同样需要验证。在 nginx 1.28.0 中，显式写 burst=0 会被拒绝，尽管省略 burst 的默认超额额度就是零。无效配置不是一种更严格但正常工作的限流策略。应同时做语法检查和真实请求验证，并确认受保护 location 确实进入限流阶段，而不是在更早的 rewrite 阶段通过 return 提前结束。 六客户端计数假定在额度恢复前到达。请求速率决定不限制长时间并发占用；旧标签链接保留，显示名称已为“漏桶”。 快速验证 下文结果归属于历史文章报告，本轮没有重跑；保留的验证文件中未找到原始集成运行日志。运行需备好本地固定镜像并启用 Python 断言；清理仅尽力执行，不能据此保证所有资源已删除。 将脚本保存为 check-burst.py，准备 Python、Docker 和固定镜像后执行。记录环境使用 nginx 1.28.0 和真实 HTTP 后端。每个案例采用独立的公开测试 key、每秒一个请求的速率，并同时放行六个客户端。nginx 在响应头中暴露本次限流决定，入口只发布到宿主回环，结束后尝试清理自己的实验资源。预期计数假定请求在下一次额度恢复前到达；调度延迟可能使这个时间前提失效： ...