深入理解 Nginx 限流：背景、原理、能力边界与实战示例

最新推荐文章于 2025-12-05 17:02:52 发布

原创最新推荐文章于 2025-12-05 17:02:52 发布 · 852 阅读

12 ·

CC 4.0 BY-SA版权

文章标签：

#nginx #java #运维 #前端 #github

点击上方“程序猿技术大咖”，关注并选择“设为星标”

回复“加群”获取入群讨论资格！

在现代互联网系统中，“限流”已经是一个绕不开的话题。随着用户规模增长、业务场景复杂化、恶意流量与突发流量不断出现，限流成为保障系统稳定性的关键手段。而作为最广泛使用的 Web 服务器和反向代理组件，Nginx 在限流方面能力强、性能高、部署简单，是大多数系统流量治理的第一道防线。

本文将从限流背景、Nginx 限流原理、能够做到的能力边界、典型应用场景，并配合多个完整配置示例进行深入讲解。

1、为什么需要限流？（背景与动机）

限流的核心目标是：

防止突发或恶意流量把系统压垮，保持服务稳定可用。

在实际业务中，限流解决的问题包括：

1) 防止单 IP 或单用户恶意刷请求

如爬虫、DDOS、小脚本不停访问同一个接口，导致服务不可用。

2) 防止突发流量击穿后端系统

后端数据库、RPC 服务、第三方接口通常都是“贵重资源”，并发能力有限。

3). 平稳系统负载，保持整体性能

如果没有限流，有突发高峰时 CPU、内存、连接数可能飙升，引发雪崩。

4). 做 API 调用规范化和 SLA 管控

如开放平台、企业 API 必须限制用户每秒调用次数。

5. 防止单个接口成为瓶颈

一些接口耗时长或资源占用大，需要限流避免过载。

在这些问题面前，Nginx 的限流往往作为第一道“入口级”防线，成本低、效果好，部署灵活。

2、Nginx 是如何做限流的？

Nginx 内置两套限流机制，对应两类场景。

1) 基于 `limit_req` 的请求速率限流（令牌桶）

用于限制 每秒请求速率（QPS）
底层是 漏桶/令牌桶算法
粒度可按 IP、URL、用户标识等

例如：

1 秒只允许 1 次访问，多余的就被 503 拒绝

2) 基于 limit_conn 的连接数限流

限制客户端最大并发连接数
常用于：
- 文件下载
- 大量长连接
- 防止某个 IP 占满连接池

3、Nginx 限流能做到什么程度？

很多人关心 Nginx 限流到底能做到多强，下面是能力范围：

1) 性能维度：非常高效（C 语言 + 内存共享）

限流数据存储在 共享内存（shm） 中
查找使用红黑树，O(log n)
单机每秒可承载 10~30 万级限流判断
不额外占用 worker 内存

适合作为高性能入口网关限流。

2) 限流维度：灵活但仅限“入口级”策略

可按：

IP
Cookie
Header
URL 维度
自定义 user key（如 userId）

但不能做到：

分布式限流（需要 Redis + Lua 或 gateway）
多维度复杂策略（如组合规则）
动态策略（配置变更需 reload）

3) 控制效果维度

Nginx 能实现：

硬限流（超过拒绝）
软限流（burst + nodelay）
阈值分段控制
慢速拒绝延迟（“雨露均沾”策略）

但不能做到：

按响应状态反馈流量
按服务后端负载自动调整

这些通常需要服务网关或自研流控系统。

4、Nginx 限流常见应用场景

1) 防止单 IP 恶意刷接口

如登录接口、短信接口、下单接口。

2) 防止大流量瞬间涌入

特别是活动、营销场景。

3) 限制 API 访问速率

比如免费 API 每秒 1 次，付费用户每秒 10 次。

4) 保护后端连接数

阻挡下载服务、流媒体服务的恶意并发。

5) 网关统一限流

比把限流逻辑放在业务更高效。

5、Nginx 限流详解 + 完整配置示例

下面通过多个典型实战示例深入解释。

示例 1：按 IP 每秒限制访问次数（limit_req）

需求：

同一个 IP 每秒只能访问 5 次，多余的请求直接拒绝。

配置：

http {    # 限流区域：10MB 共享内存，大概可存 160,000 个 IP 状态    limit_req_zone $binary_remote_addr zone=req_limit_per_ip:10m rate=5r/s;    server {        location /api/ {            limit_req zone=req_limit_per_ip burst=10 nodelay;        }    }}

说明：

rate=5r/s：每秒允许 5 次
burst=10：允许瞬间突发 10 次（缓冲区）
nodelay：超过 5 次立即消费 burst，不排队

效果：

平稳状态每秒 5 个
瞬间可峰值达到 15（5 + 10 burst）
超过 burst 的请求立即 503

示例 2：按接口粒度限流（不同接口不同规则）

limit_req_zone $binary_remote_addr zone=login_limit:5m rate=3r/m;limit_req_zone $binary_remote_addr zone=sms_limit:5m rate=1r/10m;server {    location /login {        limit_req zone=login_limit burst=5;    }    location /sendSms {        limit_req zone=sms_limit burst=1;    }}

说明：

登录接口更频繁，3 次/分钟
短信接口更严格，10 分钟 1 次

精细化限流非常常见于业务风控系统。

示例 3：按用户 ID 限流（header / cookie 维度）

需求：

按 userId 限流，而不是按 IP。

假设客户端请求 header 中有：X-User-ID: 123

配置：

limit_req_zone $http_x_user_id zone=user_limit:10m rate=10r/s;server {    location /api/ {        limit_req zone=user_limit burst=20 nodelay;    }}

说明：

通过 $http_x_user_id 实现业务维度限流，这种方式：

更公平（同一个 IP 下多个用户不会互相影响）
常用于认证后的业务接口

示例 4：限制单 IP 并发连接（limit_conn）

需求：

单个 IP 最多 2 个并发请求连接。

配置：

limit_conn_zone $binary_remote_addr zone=conn_ip_limit:10m;server {    location /download/ {        limit_conn conn_ip_limit 2;    }}

用于：

下载服务
流媒体服务
大文件访问
防止单 IP 占满连接池

示例 5：综合限流（请求速率 + 并发连接）

很多实际场景要同时满足多个限流规则：

limit_req_zone  $binary_remote_addr zone=req_limit:10m rate=10r/s;limit_conn_zone $binary_remote_addr zone=conn_limit:10m;server {    location / {        # 限 QPS        limit_req zone=req_limit burst=20;        # 限并发连接        limit_conn conn_limit 5;    }}