Nginx通过limit_conn、limit_req与后端健康检查实现轻量级流量治理与熔断：limit_conn按$binary_remote_addr限并发连接，limit_req以漏桶算法控请求速率，结合upstream状态动态降级或返回503，形成“限流+熔断”闭环。
通过 Nginx 实现流量治理与熔断控制，核心是利用其原生模块在入口层做轻量、高效、低延迟的干预，无需侵入业务代码。关键不在于堆砌功能，而在于分层设计：用 limit_conn 控制连接数底线，用 limit_req 管理请求节奏，再结合后端健康状态动态调整策略，形成“限流 + 熔断”的闭环。
用 limit_conn 控制并发连接数
这是最基础的“守门”手段，防止连接耗尽系统资源（如文件描述符、内存）。它按客户端 IP 统计当前活跃连接数，超阈值直接拒绝新连接（返回 503）。
- 优先使用
$binary_remote_addr定义限流键，比$remote_addr节省内存约 60% - 共享内存区大小要够用：1MB 约存 1.6 万个 IP 的连接状态，10MB 可支撑百万级独立客户端
- 阈值设置需参考后端真实承载力——例如后端单实例最大处理 80 并发，Nginx 可设为 100，留出缓冲余量
- 配置示例：
limit_conn_zone $binary_remote_addr zone=conn_per_ip:10m;limit_conn conn_per_ip 50;
用 limit_req 实现请求速率限制
Nginx 默认采用漏桶算法，平滑突发流量。它不只看“每秒多少次”，而是以毫秒级精度控制请求间隔（如 rate=10r/s ≈ 每 100ms 放行 1 个请求）。
-
burst是缓冲队列长度，允许短时超额请求排队；nodelay决定是否跳过排队直接响应——对登录、支付等低容忍延迟的接口建议开启 - 不同路径应差异化限流：登录页可宽松（
rate=5r/s, burst=10），核心 API 需严格（rate=2r/s, burst=2） - 避免全局统一 rate，否则小带宽用户和大客户会被同等压制
- 配置示例：
limit_req_zone $binary_remote_addr zone=api_rate:10m rate=3r/s;limit_req zone=api_rate burst=6 nodelay;
基于后端状态实现简易熔断
Nginx 本身不提供“自动开关”式熔断，但可通过 upstream 健康检查 + 变量判断 + 条件限流，模拟熔断行为：
- 启用
health_check或check（需 stream-lua-module），实时感知后端节点存活与响应延迟 - 当健康节点数低于阈值（如
$upstream_count < 2），动态降低limit_req的 rate，或触发return 503 - 配合
proxy_next_upstream error timeout http_500，自动摘除故障节点，避免请求打到“半死”服务上 - 更进一步可集成 Lua：调用 Prometheus API 获取后端错误率，若 >30%，临时将该 upstream 的限流 zone rate 减半
补充建议：避免常见误配
很多问题不是功能不行，而是配置反模式：
- 不要把
limit_req_zone放在server块里——必须定义在http块，否则 worker 间无法共享状态 - 别用
$remote_addr做 key：经 CDN 或代理后，它会变成中间节点 IP，导致全站被同一限流规则锁死 -
burst不是“放宽限制”，而是“增加排队容量”；没配nodelay时，burst=20 意味着第 21 个请求要等 2 秒才响应，可能已超前端 timeout - 限流日志建议单独输出（
log_format limitlog …），便于用 ELK 分析被限请求来源与路径分布
