限流 on Liangweidong's blog

分布式限流实战：Nginx + Tomcat + Guava + Redis Lua

Wed, 15 Sep 2021 00:00:00 +0800

本文写于 2021 年 9 月——彼时 Sentinel 已经在阿里系大规模落地，但中小厂仍以"自研 + Redis Lua"为主流。

一、限流分层架构

限流不是"做一次就够"，需要从边缘到核心层层设防：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


 ┌──────────┐
 用户请求 ───> │ CDN │ 第 1 层：CDN 限流（按地区/ISP）
 └────┬─────┘
 ▼
 ┌──────────┐
 │ Nginx │ 第 2 层：边缘网关限流（IP / 域名）
 └────┬─────┘
 ▼
 ┌──────────┐
 │ Tomcat │ 第 3 层：Web 容器限流（maxThreads）
 └────┬─────┘
 ▼
 ┌──────────┐
 │ 网关层 │ 第 4 层：Spring Cloud Gateway / Sentinel
 └────┬─────┘
 ▼
 ┌──────────┐
 │ 单体应用 │ 第 5 层：Guava RateLimiter
 └────┬─────┘
 ▼
 ┌──────────┐
 │ 分布式 │ 第 6 层：Redis + Lua 全局限流
 │ Redis │
 └──────────┘

核心思想：越靠近用户限流越粗（IP / 域名），越靠近业务限流越细（接口 / 用户）。

二、Nginx 限流（边缘网关层）

2.1 核心指令

Nginx 自带两个限流模块：

limit_req：限制请求速率（QPS）
limit_conn：限制并发连接数

2.2 完整配置

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44


# ===== 第一步：定义限流 zone（http 块）=====

# 根据 IP 限速：每秒 10 个请求
limit_req_zone $binary_remote_addr zone=iplimit:20m rate=10r/s;

# 根据 server 限速：每秒 1 个请求
limit_req_zone $server_name zone=serverlimit:10m rate=1r/s;

# 根据 IP 限并发：每个 IP 最多 100 个连接
limit_conn_zone $binary_remote_addr zone=perip:20m;

# 根据 server 限并发：每个 server 最多 100 个连接
limit_conn_zone $server_name zone=perserver:20m;

# ===== 第二步：在 location 应用 =====

server {
 server_name www.test.com;
 
 # 接口限流
 location /access-limit/ {
 proxy_pass http://127.0.0.1:8080/;
 
 # IP 限速（burst=2 允许瞬时 2 个排队，nodelay 不延迟立即处理）
 limit_req zone=iplimit burst=2 nodelay;
 # server 限速
 limit_req zone=serverlimit burst=2 nodelay;
 # IP 限并发 100
 limit_conn zone=perip 100;
 # server 限并发 100
 limit_conn zone=perserver 1;
 # 限流触发时返回 504（默认 503）
 limit_req_status 504;
 limit_conn_status 504;
 }
 
 # 限速下载
 location /download/ {
 # 前 100m 不限速
 limit_rate_after 100m;
 # 之后限速 256k/s
 limit_rate 256k;
 }
}

2.3 关键参数

burst=2：允许瞬时超出 rate 2 个请求排队等待
nodelay：排队不延迟，超出的请求立即返回 503（默认是延迟处理）
rate=10r/s：每秒 10 个请求（也支持 30r/m 每分钟 30 个）

三、Tomcat 限流（Web 容器层）

3.1 核心配置

Tomcat 8.5 通过 conf/server.xml 配置最大线程数：

1
2
3
4
5
6


<Connector port="8080"
 protocol="HTTP/1.1"
 connectionTimeout="20000"
 maxThreads="150" <!-- 最大线程数 -->
 acceptCount="100" <!-- 等待队列长度 -->
 redirectPort="8443" />

工作原理：

当并发请求 > maxThreads（默认 150）时，请求进入等待队列
等待队列满后，新请求被拒绝
天然限流

3.2 调优建议

小贴士：maxThreads 默认 150（Tomcat 8.5.42），但不是越大越好：

每开 1 个线程 → 1MB JVM 内存（线程栈）
线程越多 → GC 负担越重
OS 限制：Windows 每进程 ≤ 2000 线程，Linux 每进程 ≤ 1000 线程

经验值：8 核 16G 机器配 maxThreads=400 较合理，再多就是 GC 抖动的开始。

四、单体应用限流（Guava RateLimiter）

4.1 引入依赖

1
2
3
4
5
6


<!-- https://mvnrepository.com/artifact/com.google.guava/guava -->
<dependency>
 <groupId>com.google.guava</groupId>
 <artifactId>guava</artifactId>
 <version>31.1-jre</version>
</dependency>

4.2 简单使用

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


@Slf4j
@RestController
@RequestMapping("/limit")
public class LimitController {
 
 // 限流策略：1 秒钟 2 个请求
 private final RateLimiter limiter = RateLimiter.create(2.0);
 
 @GetMapping("/test1")
 public String testLimiter() {
 // 500 毫秒内，没拿到令牌就降级
 boolean tryAcquire = limiter.tryAcquire(500, TimeUnit.MILLISECONDS);
 
 if (!tryAcquire) {
 log.warn("进入服务降级，时间{}", LocalDateTime.now());
 return "当前排队人数较多，请稍后再试！";
 }
 
 log.info("获取令牌成功，时间{}", LocalDateTime.now());
 return "请求成功";
 }
}

4.3 Guava 限流模式

模式	类	特点
平滑突发（SmoothBursty）	`RateLimiter.create(permitsPerSecond)`	启动即可满速率
平滑预热（SmoothWarmingUp）	`RateLimiter.create(permitsPerSecond, warmupPeriod, unit)`	启动后有预热期，逐步提到配置速率

4.4 自定义注解 + AOP（接口级限流）

注解：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.METHOD})
@Documented
public @interface Limit {
 String key() default ""; // 资源 key
 double permitsPerSecond(); // QPS
 long timeout(); // 最大等待时间
 TimeUnit timeunit() default TimeUnit.MILLISECONDS;
 String msg() default "系统繁忙,请稍后再试.";
}

AOP 切面：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37


@Slf4j
@Aspect
@Component
public class LimitAop {
 
 private final Map<String, RateLimiter> limitMap = Maps.newConcurrentMap();
 
 @Around("@annotation(com.example.limit.Limit)")
 public Object around(ProceedingJoinPoint joinPoint) throws Throwable {
 MethodSignature signature = (MethodSignature) joinPoint.getSignature();
 Method method = signature.getMethod();
 Limit limit = method.getAnnotation(Limit.class);
 
 if (limit != null) {
 String key = limit.key();
 RateLimiter rateLimiter = limitMap.computeIfAbsent(
 key, k -> RateLimiter.create(limit.permitsPerSecond())
 );
 
 // 拿令牌
 boolean acquire = rateLimiter.tryAcquire(limit.timeout(), limit.timeunit());
 if (!acquire) {
 log.debug("令牌桶={}，获取令牌失败", key);
 this.responseFail(limit.msg());
 return null;
 }
 }
 return joinPoint.proceed();
 }
 
 private void responseFail(String msg) {
 HttpServletResponse response = ((ServletRequestAttributes) 
 RequestContextHolder.getRequestAttributes()).getResponse();
 ResultData<Object> resultData = ResultData.fail(ReturnCode.LIMIT_ERROR.getCode(), msg);
 WebUtils.writeJson(response, resultData);
 }
}

Controller：

1
2
3
4
5
6
7


@GetMapping("/test2")
@Limit(key = "limit2", permitsPerSecond = 1, timeout = 500, 
 timeunit = TimeUnit.MILLISECONDS, msg = "排队中，请稍候")
public String limit2() {
 log.info("limit2 获取令牌成功");
 return "ok";
}

4.5 IP 级限流

思路：每个 IP 一个 RateLimiter，缓存到 LoadingCache。

限流工具类：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43


public class RateLimitUtil {
 /** 缓存：1000 个 IP，过期 1 天 */
 private static LoadingCache<String, RateLimiter> limitCaches = CacheBuilder.newBuilder()
 .maximumSize(1000)
 .expireAfterWrite(1, TimeUnit.DAYS)
 .build(new CacheLoader<String, RateLimiter>() {
 @Override
 public RateLimiter load(String key) {
 double perSecond = RateLimitUtil.getCacheKeyPerSecond(key);
 return RateLimiter.create(perSecond);
 }
 });
 
 /** 唯一 key = 资源名:ip:perSecond */
 public static String generateCacheKey(Method method, HttpServletRequest request) {
 RateLimit rateLimit = method.getAnnotation(RateLimit.class);
 StringBuilder cacheKey = new StringBuilder(rateLimit.name() + ":");
 cacheKey.append(getIpAddr(request) + ":");
 cacheKey.append(rateLimit.perSecond());
 return cacheKey.toString();
 }
 
 public static double getCacheKeyPerSecond(String cacheKey) {
 return Double.parseDouble(cacheKey.split(":")[2]);
 }
 
 public static String getIpAddr(HttpServletRequest request) {
 String ip = request.getHeader("x-forwarded-for");
 if (ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) {
 ip = request.getHeader("Proxy-Client-IP");
 }
 if (ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) {
 ip = request.getRemoteAddr();
 }
 // 多级代理取第一个 IP
 if (ip != null && ip.length() > 15) {
 if (ip.indexOf(",") > 0) {
 ip = ip.substring(0, ip.indexOf(","));
 }
 }
 return ip;
 }
}

五、分布式应用限流（Redis + Lua 令牌桶）

5.1 为什么需要 Redis 限流

Guava RateLimiter 是进程内的，集群部署时每个节点都有一份独立的限流器——比如 3 节点配 100 QPS，实际可能是 300 QPS。

Redis 限流 = 全集群共享一份限流计数。

5.2 令牌桶算法（Lua 实现）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


-- KEYS[1]: 接口唯一 ID
-- ARGV[1]: max_token（桶容量）
-- ARGV[2]: token_rate（每秒产生令牌数）
-- ARGV[3]: current_time（当前时间戳，毫秒）

local ratelimit_info = redis.pcall('HMGET', KEYS[1], 'last_time', 'current_token')
local last_time = ratelimit_info[1]
local current_token = tonumber(ratelimit_info[2])
local max_token = tonumber(ARGV[1])
local token_rate = tonumber(ARGV[2])
local current_time = tonumber(ARGV[3])

if current_token == nil then
 current_token = max_token
 last_time = current_time
else
 local past_time = current_time - last_time
 
 if past_time > 1000 then
 current_token = current_token + token_rate
 last_time = current_time
 end
 
 -- 防止溢出
 if current_token > max_token then
 current_token = max_token
 last_time = current_time
 end
end

local result = 0
if (current_token > 0) then
 result = 1
 current_token = current_token - 1
 last_time = current_time
end

redis.call('HMSET', KEYS[1], 'last_time', last_time, 'current_token', current_token)
return result

关键点：

每个接口的 key（如 uri:/api/order/create）对应一个 Hash
Hash 存 last_time（上次请求时间）+ current_token（当前桶内令牌数）
每隔 1000ms 自动补充 token_rate 个令牌
拿不到令牌返回 0，拿到了返回 1 并减 1

5.3 Spring Boot 集成

Redis 序列化配置：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


@Bean(value = "redisTemplate")
@Primary
public RedisTemplate redisTemplate(RedisConnectionFactory factory) {
 RedisTemplate<String, Object> template = new RedisTemplate<>();
 template.setConnectionFactory(factory);
 
 ObjectMapper objectMapper = new ObjectMapper();
 objectMapper.setSerializationInclusion(JsonInclude.Include.NON_NULL);
 
 StringRedisSerializer stringRedisSerializer = new StringRedisSerializer();
 Jackson2JsonRedisSerializer jsonRedisSerializer = new Jackson2JsonRedisSerializer(Object.class);
 jsonRedisSerializer.setObjectMapper(objectMapper);
 
 template.setKeySerializer(stringRedisSerializer);
 template.setHashKeySerializer(stringRedisSerializer);
 template.setValueSerializer(jsonRedisSerializer);
 template.setHashValueSerializer(jsonRedisSerializer);
 return template;
}

限流工具类：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


public class RedisLimiterUtils {
 
 private static StringRedisTemplate stringRedisTemplate = 
 ApplicationContextUtils.applicationContext.getBean(StringRedisTemplate.class);
 
 /**
 * 拿令牌
 * @param key 请求 ID（如接口 URI）
 * @param max 桶容量
 * @param rate 每秒生成令牌数
 * @return true=拿到，false=限流
 */
 public static boolean tryAcquire(String key, int max, int rate) {
 List<String> keyList = new ArrayList<>(1);
 keyList.add(key);
 
 DefaultRedisScript<Long> script = new DefaultRedisScript<>();
 script.setResultType(Long.class);
 script.setScriptText(LUA_SCRIPT);
 
 Long result = stringRedisTemplate.execute(
 script, keyList,
 Integer.toString(max),
 Integer.toString(rate),
 Long.toString(System.currentTimeMillis())
 );
 
 return Long.valueOf(1).equals(result);
 }
}

5.4 注解 + 拦截器

注解：

1
2
3
4
5
6
7


@Inherited
@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
public @interface RateLimit {
 int capacity() default 100; // 桶容量
 int rate() default 10; // 每秒令牌数
}

拦截器：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


@Component
public class RateLimiterIntercept implements HandlerInterceptor {
 
 @Override
 public boolean preHandle(HttpServletRequest request, HttpServletResponse response,
 Object handler) throws Exception {
 if (handler instanceof HandlerMethod) {
 HandlerMethod handlerMethod = (HandlerMethod) handler;
 Method method = handlerMethod.getMethod();
 
 RateLimit rateLimit = AnnotationUtils.findAnnotation(method, RateLimit.class);
 if (Objects.isNull(rateLimit)) {
 rateLimit = AnnotationUtils.findAnnotation(
 handlerMethod.getBean().getClass(), RateLimit.class);
 }
 
 if (Objects.isNull(rateLimit)) return true;
 
 // 拿令牌，失败抛异常
 if (!RedisLimiterUtils.tryAcquire(
 request.getRequestURI(),
 rateLimit.capacity(),
 rateLimit.rate())) {
 throw new TimeOutException("系统繁忙，请稍后再试");
 }
 }
 return true;
 }
}

注册拦截器：

1
2
3
4
5
6
7
8


@Configuration
public class WebConfigurer implements WebMvcConfigurer {
 @Override
 public void addInterceptors(InterceptorRegistry registry) {
 registry.addInterceptor(new RateLimiterIntercept())
 .addPathPatterns("/**");
 }
}

六、4 种限流方案对比

维度	Nginx	Tomcat	Guava	Redis + Lua
粒度	IP / Server	容器线程	接口	接口 / 用户 / 全局
作用层	边缘	容器	单体应用	分布式
性能	极高	高	高	中（网络 IO）
跨节点	是	否	否	是
实现成本	配置	配置	引入 + AOP	Lua + 工具类
推荐场景	公网入口	单体应用	单体应用	分布式集群

七、面试常问

Q：令牌桶和漏桶有什么区别？ A：

令牌桶：以恒定速率生产令牌，请求消耗令牌。允许突发流量（桶满时能瞬时处理多个请求）
漏桶：以恒定速率流出请求，水（请求）任意速率流入桶。强制平滑，不允许突发

Q：为什么 Redis 限流要选 Lua 脚本？ A：Redis 单线程 + Lua 原子执行，整个限流判断在一次 RTT 内完成。如果用 Java 代码分多次调用（HMGET → 业务判断 → HMSET），中间被打断会导致计数错乱。

Q：Guava RateLimiter 和 Redis 限流怎么选？ A：

单实例 / 性能敏感：Guava（避免 Redis 网络 IO）
多实例 / 严格全局限流：Redis（保证全集群总和）

Q：Nginx 的 burst 和 nodelay 怎么理解？ A：burst=10 nodelay 表示允许 10 个请求瞬时超出 rate，但立即处理不排队。等价于"令牌桶初始有 10 个令牌，被拿完后必须等下一个令牌生成"。

八、小结

限流分层：CDN → Nginx → Tomcat → Gateway → 单体应用 → 分布式 Redis
Nginx：边缘限流首选，配置简单性能高
Tomcat：maxThreads 调优是基本功
Guava：单体内 AOP + 注解最优雅
Redis + Lua：分布式场景的必选，原子性 + 全局一致

Java 微服务治理：Sentinel 限流降级 + Spring Boot Admin 监控

Mon, 15 Jun 2020 00:00:00 +0800

微服务架构跑起来后，稳定性保障是头等大事——限流、熔断、降级、监控告警缺一不可。本篇把 Alibaba Sentinel 限流和 Spring Boot Admin 监控两套核心组件的 Docker 化部署整理清楚。

阅读对象：Java 后端 / 微服务架构师 覆盖范围：Sentinel Dashboard 部署 + Spring Boot Admin 部署 + 微服务接入 + 限流规则配置 + 告警通知 + Loki 日志集成

一、微服务治理全景

1
2
3
4
5
6
7
8
9


微服务治理体系
 ├─ 服务注册发现：Nacos / Consul / Eureka
 ├─ 配置中心：Nacos / Apollo
 ├─ API 网关：Spring Cloud Gateway / Zuul
 ├─ 服务调用：OpenFeign / Dubbo
 ├─ 服务熔断：Sentinel / Hystrix（已停维）
 ├─ 链路追踪：Sleuth + Zipkin / SkyWalking
 ├─ 监控告警：Spring Boot Admin / Prometheus + Grafana
 └─ 日志聚合：ELK / Loki

本篇聚焦：Sentinel（限流熔断）+ Spring Boot Admin（监控）。

When to use Sentinel：

微服务架构，需要防雪崩

双 11、618 大促流量控制

第三方接口调用熔断

秒杀、抢购等高并发场景

When to use Spring Boot Admin：

Spring Boot 微服务集群监控

JVM 指标 / 线程 / 内存 / 日志统一查看

实时健康检查 + 告警

二、Alibaba Sentinel

2.1 简介

Sentinel 是阿里开源的流量控制 / 熔断降级组件，2018 年开源：

维度	Sentinel	Hystrix（已停维）	Resilience4j
流量控制	✅ 多种策略	简单	简单
熔断降级	✅	✅	✅
系统自适应保护	✅（Load / CPU / RT）	❌	❌
控制台	✅ 可视化	简单	无
规则持久化	✅ Nacos / Apollo / 文件	配置中心	代码
社区活跃度	高	已停维	中

2.2 Sentinel Dashboard 部署

下载：v1.8.6

1
2
3
4
5
6
7
8
9


# 1. docker 启动
docker run -d --name sentinel --restart=always \
 -p 18080:8080 \
 -v /home/project/safety/sentinel/jar:/jar \
 lwd/jdk:8u371 \
 java -Dserver.port=8080 \
 -Dcsp.sentinel.dashboard.server=localhost:8080 \
 -Dproject.name=sentinel-dashboard \
 -jar /jar/sentinel-dashboard-1.8.6.jar

docker-compose 完整版：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


version: "3"
x-logging: &loki-logging
 driver: loki
 options:
 loki-url: "http://internal.example.com:3100/loki/api/v1/push"
 max-size: "50m"
 max-file: "10"
 loki-pipeline-stages: |
 - multiline:
 firstline: '^\[\d{2}:\d{2}:\d{2} \w{4}\]'
services:
 sentinel:
 image: lwd/jdk:8u371
 container_name: sentinel
 restart: always
 logging: *loki-logging
 network_mode: host
 volumes:
 - "/home/project/safety/sentinel/jar:/jar"
 command: java -Dserver.port=8080 \
 -Dcsp.sentinel.dashboard.server=localhost:8080 \
 -Dproject.name=sentinel-dashboard \
 -jar /jar/sentinel-dashboard-1.8.6.jar

2.3 访问 Dashboard

1
2


http://<IP>:18080
默认账号：sentinel / sentinel

2.4 微服务接入 Sentinel

添加依赖：

1
2
3
4


<dependency>
 <groupId>com.alibaba.cloud</groupId>
 <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>

配置：

1
2
3
4
5
6
7
8
9


spring:
 application:
 name: my-service
 cloud:
 sentinel:
 transport:
 dashboard: localhost:18080  # Sentinel Dashboard 地址
 port: 8719 # 与 Dashboard 通信端口
 eager: true # 启动时立刻注册

限流示例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


@RestController
public class OrderController {

 @GetMapping("/order/create")
 @SentinelResource(value = "createOrder", blockHandler = "handleBlock")
 public String createOrder() {
 return "success";
 }

 // 限流后的回调
 public String handleBlock(BlockException e) {
 return "系统繁忙，请稍后重试";
 }
}

2.5 限流规则配置

Dashboard → 簇点链路 → 找到 createOrder → 流控：

1
2
3
4


阈值类型：QPS
单机阈值：100
流控模式：直接
流控效果：快速失败

效果：每秒超过 100 个请求 → 触发限流 → 调用 handleBlock。

2.6 熔断降级

Dashboard → 熔断规则：

1
2
3
4
5


资源名：createOrder
熔断策略：慢调用比例
最大 RT：500ms
熔断时长：10s
最小请求数：5

效果：5 个请求中慢调用（>500ms）占比超阈值 → 熔断 10s。

2.7 规则持久化（生产必做）

默认规则存内存，重启就丢。生产用 Nacos 持久化：

1
2
3
4


<dependency>
 <groupId>com.alibaba.csp</groupId>
 <artifactId>sentinel-datasource-nacos</artifactId>
</dependency>

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


spring:
 cloud:
 sentinel:
 datasource:
 ds1:
 nacos:
 server-addr: nacos.internal.example.com:8848
 dataId: sentinel-flow-rules
 groupId: DEFAULT_GROUP
 rule-type: flow

三、Spring Boot Admin

3.1 简介

Spring Boot Admin 是 Spring Boot 应用的统一监控中心：

应用健康检查（UP / DOWN / OFFLINE / UNKNOWN）
JVM 指标（内存、线程、GC、堆栈）
HTTP 请求追踪
日志查看（实时拉取）
配置信息（Spring Environment）
告警通知（邮件 / Slack / PagerDuty / 钉钉 / 飞书）

3.2 创建 Admin Server

pom.xml：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


<dependency>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
 <groupId>de.codecentric</groupId>
 <artifactId>spring-boot-admin-starter-server</artifactId>
 <version>2.5.6</version>
</dependency>
<dependency>
 <groupId>org.projectlombok</groupId>
 <artifactId>lombok</artifactId>
 <optional>true</optional>
</dependency>

Application.java：

1
2
3
4
5
6
7


@SpringBootApplication
@EnableAdminServer
public class SpringbootAdminApplication {
 public static void main(String[] args) {
 SpringApplication.run(SpringbootAdminApplication.class, args);
 }
}

application.yml：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


server:
 port: 4396
spring:
 application:
 name: springbootadmin
 boot:
 admin:
 notify:
 slack:
 enabled: true
 webhook-url: https://hooks.slack.com/services/{{SLACK_TOKEN}}
 mail:
 enabled: true
 from: noreply@example.com

3.3 部署

1
2
3
4
5


docker run -d --name springbootadmin --restart=always \
 -p 14396:4396 \
 -v /home/docker/springboot-admin/jar:/jar \
 lwd/jdk:8u371 \
 java -jar /jar/SpringbootAdmin-0.0.1-SNAPSHOT.jar

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


# docker-compose
version: "3"
x-logging: &loki-logging
 driver: loki
 options:
 loki-url: "http://internal.example.com:3100/loki/api/v1/push"
services:
 admin:
 image: lwd/jdk:8u371
 container_name: admin
 restart: always
 logging: *loki-logging
 network_mode: host
 volumes:
 - "/home/project/safety/admin/jar:/jar"
 command: java -jar /jar/SpringbootAdmin-0.0.1-SNAPSHOT.jar

访问：

1

http://<IP>:14396

3.4 微服务注册到 Admin

添加依赖：

1
2
3
4
5


<dependency>
 <groupId>de.codecentric</groupId>
 <artifactId>spring-boot-admin-starter-client</artifactId>
 <version>2.5.6</version>
</dependency>

配置：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


spring:
 boot:
 admin:
 client:
 url: http://admin.internal.example.com:14396
 instance:
 name: my-service
 prefer-ip: true
management:
 endpoints:
 web:
 exposure:
 include: "*"
 endpoint:
 health:
 show-details: always

重启微服务 → 30 秒后 Admin 后台就能看到这个应用。

3.5 Admin 后台功能

Applications → 点击应用：

Details：基本信息
Metrics：JVM / 内存 / 线程
Environment：配置
Logging：实时日志（Level 实时调整）
JVM：堆栈、线程、GC
Mappings：REST API 列表
Trace：最近 HTTP 请求
Threads：线程详情（可以 dump 堆栈）
Heapdump：下载堆转储

3.6 告警通知

邮件告警（最常用）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


spring:
 mail:
 host: smtp.example.com
 port: 465
 username: noreply@example.com
 password: {{SMTP_PASS}}
 boot:
 admin:
 notify:
 mail:
 enabled: true
 to:
 - ops-team@example.com
 from: noreply@example.com

Slack 告警：

1
2
3
4
5
6
7
8


spring:
 boot:
 admin:
 notify:
 slack:
 enabled: true
 webhook-url: https://hooks.slack.com/services/{{TOKEN}}
 channel: '#alerts'

钉钉告警（自定义 NotificationListener）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


@Component
public class DingTalkNotifier implements Notifier {
 @Override
 public void notify(InstanceEvent event) {
 if (event instanceof InstanceStatusChangedEvent) {
 // 调钉钉 Webhook
 sendToDingTalk(((InstanceStatusChangedEvent) event).getInstance().getRegistration().getName());
 }
 }
}

四、限流 vs 监控告警的配合

场景	Sentinel	Spring Boot Admin
应用崩溃	熔断防止雪崩	告警 + JVM 监控
接口慢	慢调用比例熔断	Thread dump 分析
流量激增	QPS 限流	QPS / TPS 指标
内存爆	（不管）	JVM 内存告警
依赖服务挂	熔断下游	Health Check 告警

生产推荐两者都上——Sentinel 做"主动防御"，Admin 做"被动感知"。

五、典型坑位

5.1 Sentinel Dashboard 看不到应用

修复：

1
2
3
4
5
6


spring:
 cloud:
 sentinel:
 transport:
 dashboard: localhost:18080  # 用 IP，不用 localhost
 eager: true # 启动时主动注册

触发初始化：访问任意接口（Sentinel 是懒加载，没人调用就不知道有这个接口）。

5.2 限流规则不生效

修复：

1
2
3
4
5


// 1. 必须加 @SentinelResource
@SentinelResource(value = "createOrder", blockHandler = "handleBlock")

// 2. 或者用 URL 流控（不推荐）
// Dashboard → 流控规则 → 资源名填 /order/create

5.3 Admin 显示应用 OFFLINE

修复：

1
2
3
4
5
6


spring:
 boot:
 admin:
 client:
 instance:
 prefer-ip: true

应用注册到 Admin 时用 IP，不是 hostname。

5.4 Admin 看不到日志

修复：

1
2
3
4
5


logging:
 file:
 name: /app/logs/myapp.log
 pattern:
 file: "%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n"

日志文件路径必须固定，Admin 才能拉取。

六、生产级架构

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


 ┌─────────────────┐
 │ Spring Cloud │
 │ Gateway │
 └────────┬────────┘
 │
 ┌──────────────────────┼──────────────────────┐
 │ │ │
 ┌──────▼──────┐ ┌───────▼──────┐ ┌───────▼──────┐
 │ service-a │ │ service-b │ │ service-c │
 └──────┬──────┘ └───────┬──────┘ └───────┬──────┘
 │ │ │
 │ 注册信息 + 健康检查 + JVM 指标 │
 └──────────────────────┼──────────────────────┘
 │
 ┌──────────▼──────────┐
 │ Spring Boot Admin │
 │ Dashboard │
 └─────────────────────┘
 │
 ┌──────────▼──────────┐
 │ Sentinel │
 │ Dashboard │
 └─────────────────────┘

所有微服务都做 3 件事：

注册到 Nacos
监控到 Spring Boot Admin
限流配置到 Sentinel

七、Spring Boot Admin 高级用法

7.1 日志级别动态调整

Admin 后台 → Logs → 选择 logger → 改 level（如 INFO → DEBUG）。

实时生效，不需要重启应用。

7.2 线程 Dump

Admin 后台 → Threads → Download → 拿 .tdump 文件分析。

典型场景：应用 hang 住时直接 dump 线程看是哪里卡了。

7.3 Heap Dump

Admin 后台 → Heapdump → 下载 .hprof → 用 VisualVM / MAT 分析内存泄漏。

7.4 集成 Spring Security

Admin 后台默认无认证——生产必加：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


@Configuration
public class SecurityConfig {
 @Bean
 public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
 http
 .authorizeHttpRequests(authz -> authz
 .requestMatchers("/login", "/css/**", "/js/**").permitAll()
 .anyRequest().authenticated()
 )
 .formLogin(Customizer.withDefaults());
 return http.build();
 }
}

八、最佳实践清单

Sentinel + Spring Boot Admin 一起上——防御 + 监控双保险
Sentinel 规则持久化到 Nacos——重启不丢
Admin 后台加 Spring Security——避免被公网访问
限流阈值用真实压测数据——不要拍脑袋
熔断时长 10s 起——给下游恢复时间
告警分级——P0（立即响应）/ P1（小时级）/ P2（日级）
告警去重——同一问题 5 分钟内只发一次
告警值班——on-call 机制，避免"狼来了"
JVM 指标进 Prometheus——长期趋势分析
链路追踪进 SkyWalking——慢调用根因分析

2024+ 视角补充

本文写于 2020-06，2024-2026 期间 Java 微服务治理关键演进：

Sentinel 1.8.6+ → 1.8.8+（2024-2025）：Spring Boot 3.x 兼容；JDK 17+ 强制；OpenTelemetry 集成——指标 / Trace 全打通
Sentinel 2.0 路线图（2025-Q3）：AI 限流（基于 LLM 流量预测）；自适应并发（自动调整阈值）
Spring Boot Admin 3.x（2024-2025）：Spring Boot 3.x 兼容；Micrometer Tracing 集成；WebFlux 异步应用监控
微服务治理生态（2024-2026）：
- Spring Cloud Alibaba 2023.0+：Nacos 2.x + Sentinel 1.8+ + Seata 1.8+ + RocketMQ 5.x 一站式
- Spring Cloud 2024+：逐步被 Spring Cloud OpenFeign + 独立组件取代——“Spring Cloud 套件"模式弱化
- Service Mesh（Istio 1.20+ / Linkerd 2.15+）：限流 / 熔断下沉到 Sidecar，Java 业务代码不写限流逻辑——2024+ 趋势
- 可观测三件套：Micrometer + Prometheus + Grafana + Tempo（Trace）——Sentinel 与 OpenTelemetry 融合
Spring Cloud Gateway 4.x（2024）：Reactor 2024+；Spring Cloud LoadBalancer（替代 Ribbon）
云原生时代：Spring Boot 3.4+ + K8s 1.30+ + Istio 1.20+ 是 2025+ Java 微服务黄金组合

实战建议（2025-2026 视角）：

传统 Spring Cloud 套件 → Spring Cloud Alibaba 2023.0.x 仍是 2024+ 稳态
K8s 上 → Service Mesh 优先（限流 / 熔断下沉 Sidecar）
AI 监控 → Micrometer + OpenTelemetry + LLM 异常检测（2025+ 实验性）
存量项目 → 升 Spring Boot 3.4+ + JDK 21 是 2025+ 主路线

下一步

想看 JDK 自建镜像实战（Alpine / Debian / Ubuntu）→ JDK 自建镜像实战
想看 Java 应用 Docker 化（Tomcat / Spring Boot 打包）→ Java 应用 Docker 化
想看 XXL-Job 分布式调度（任务调度平台）→ XXL-Job 分布式调度
想看 Nginx 自建镜像实战（反代安全加固）→ Nginx 自建镜像实战

限流算法完全对比：固定窗口、滑动窗口、漏桶与令牌桶

Mon, 23 Sep 2019 00:00:00 +0000

在高并发系统中，限流（Rate Limiting）是保护下游服务不被突发流量打挂的核心手段。限流算法家族里，最常见的 4 个成员是：固定窗口计数器、滑动窗口计数器、漏桶算法、令牌桶算法。它们各有取舍，分别适用于不同的业务场景。这篇文章会带你用 4 张原理图 + 代码实现 + 选型建议，把这 4 个算法彻底讲透。

为什么学限流？ 限流是后端面试几乎必考的题目（无论是社招还是校招），因为它同时考察你算法理解、并发编程、系统设计三大能力。更重要的是，主流的微服务网关（Spring Cloud Gateway / Sentinel / Kong / Envoy）底层都跑着这些算法。

一、为什么需要限流？

在动手学算法之前，先搞清楚"限流到底在防什么"：

风险	说明
雪崩	一个慢下游拖垮整个调用链
资源耗尽	数据库连接池/线程池被打满
恶意流量	爬虫/羊毛党/CC 攻击
突发流量	秒杀、热点事件、明星离婚导致 10x 流量尖刺

限流的目标是：在系统容量范围内接待尽可能多的"好"请求，把"坏"请求挡在外面。

二、固定窗口计数器（Fixed Window Counter）

2.1 算法原理

图源说明：上图来自原 限流/算法.md 文档，展示了固定窗口计数器把时间轴切成等长窗口（图中每个矩形就是一个窗口），每个窗口内独立计数的结构。

核心思想：

将时间划分为多个等长的窗口（例如 1 秒一个窗口）
在每个窗口内每来一个请求就将计数器加一
如果计数器超过了限制数量，则本窗口内所有的请求都被丢弃
当时间到达下一个窗口时，计数器重置

2.2 致命缺陷：边界双倍突发

固定窗口是最简单的算法，但有一个著名的"边界问题"——它可能让通过请求量允许为限制的两倍。

图源说明：上图演示了"边界双倍突发"问题。

例子：限制 1 秒内最多通过 5 个请求。

第 1 个窗口的最后半秒：通过了 5 个请求
第 2 个窗口的前半秒：又通过了 5 个请求

看起来是在 1 秒内通过了 10 个请求——两倍于限制！系统在临界点承受了远超设计容量的压力。

2.3 代码实现

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


import time

class FixedWindowRateLimiter:
 """固定窗口计数器：实现最简单，但有边界双倍突发的风险"""
 def __init__(self, limit: int, window_seconds: int):
 self.limit = limit
 self.window = window_seconds
 self.count = 0
 self.window_start = int(time.time())

 def allow(self) -> bool:
 now = int(time.time())
 if now - self.window_start >= self.window:
 # 进入新窗口
 self.window_start = now
 self.count = 0
 if self.count < self.limit:
 self.count += 1
 return True
 return False

2.4 优缺点

优点	缺点
实现最简单（一个计数器 + 一个时间戳）	边界双倍突发问题
内存占用最小	窗口切换时可能"突然丢一半请求"
单机/分布式都好实现	不适合"严格平滑限流"的场景

三、滑动窗口计数器（Sliding Window Counter）

3.1 算法原理

图源说明：上图展示了滑动窗口计数器把每个窗口再细分成多个小时间区间，并按时间"滑动"的机制。

核心思想：

将时间划分为多个小时间区间（如 1 秒的窗口再分成 10 个 100ms 的子区间）
在每个子区间内每来一个请求就将该子区间的计数器加一
维持一个时间窗口，占据多个子区间
每经过一个子区间的时间，则抛弃最老的一个子区间，并纳入最新的一个子区间
如果当前窗口内所有子区间的请求计数总和超过了限制数量，则本窗口内所有的请求都被丢弃

3.2 为什么解决了边界问题？

滑动窗口通过"细分 + 滑动"避免了固定窗口的双倍突发——窗口的边界是连续滑动的，不会突然从一个干净状态跳到满载状态。

3.3 精度与空间的权衡

子区间数量	精度	内存占用（每个用户）
1（=固定窗口）	最粗	O(1)
10	中	O(10)
60	细	O(60)
1000	很高	O(1000)

子区间越多，限流越精准，但每个用户/接口的内存占用越大。Cloudflare 公开的方案里就用 60 个子区间的滑动窗口。

3.4 代码实现

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


import time
from collections import deque

class SlidingWindowRateLimiter:
 """滑动窗口计数器：精度高，能避免固定窗口的边界双倍突发"""
 def __init__(self, limit: int, window_seconds: int):
 self.limit = limit
 self.window = window_seconds
 # 存 (时间戳, )，每次清理掉超过 window 的旧时间戳
 self.timestamps: deque[float] = deque()

 def allow(self) -> bool:
 now = time.time()
 # 弹出过期的时间戳
 while self.timestamps and self.timestamps[0] <= now - self.window:
 self.timestamps.popleft()
 if len(self.timestamps) < self.limit:
 self.timestamps.append(now)
 return True
 return False

3.5 优缺点

优点	缺点
解决了固定窗口的边界问题	内存占用更大
精度可调	实现稍复杂
适合 API 限流、爬虫限频	单机原子性需要锁/原子操作

四、漏桶算法（Leaky Bucket）

4.1 算法原理

图源说明：上图展示了漏桶算法把请求视作"水滴"放入"漏桶"，再以固定速率向外"漏"出请求的机制。

核心思想：

将每个请求视作"水滴"放入"漏桶"进行存储
“漏桶"以固定速率向外"漏"出请求来执行
如果"漏桶"空了则停止"漏水”
如果"漏桶"满了则多余的"水滴"会被直接丢弃

4.2 核心特性：强制平滑输出

漏桶最大的特点是输出速率恒定——无论进来的流量多不均匀，出去的速率永远是 leak_rate。这非常适合"下游服务处理能力固定“的场景（如调用银行接口、调用第三方 API）。

4.3 缺陷：无法应对突发

漏桶的缺陷也很明显——当短时间内有大量的突发请求时，即便此时服务器没有任何负载，每个请求也都得在队列中等待一段时间才能被响应。换句话说：它把"突发"给"抹平"了。

4.4 代码实现

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


import time
from collections import deque

class LeakyBucketRateLimiter:
 """漏桶算法：强制平滑输出，适合下游处理能力固定的场景"""
 def __init__(self, capacity: int, leak_rate_per_sec: float):
 """
 :param capacity: 桶容量
 :param leak_rate_per_sec: 每秒漏出的水滴数
 """
 self.capacity = capacity
 self.leak_rate = leak_rate_per_sec
 self.queue: deque[float] = deque()
 self.last_leak_time = time.time()

 def _leak(self):
 """把超过当前时间该漏出的水滴都漏掉"""
 now = time.time()
 elapsed = now - self.last_leak_time
 leaked = int(elapsed * self.leak_rate)
 if leaked > 0:
 for _ in range(min(leaked, len(self.queue))):
 self.queue.popleft()
 self.last_leak_time = now

 def allow(self) -> bool:
 self._leak()
 if len(self.queue) < self.capacity:
 self.queue.append(time.time())
 return True
 return False

4.5 优缺点

优点	缺点
输出绝对平滑，保护下游	抹掉突发——空闲时也无法利用富余容量
队列机制天然支持"等待"语义	需要额外的队列/定时器
实现直观	延迟 = 队列长度 / 漏出速率

五、令牌桶算法（Token Bucket）

5.1 算法原理

图源说明：上图展示了令牌桶算法以固定速率生成令牌、请求来临时取令牌的工作机制。

核心思想：

令牌以固定速率生成
生成的令牌放入令牌桶中存放，如果令牌桶满了则多余的令牌会直接丢弃
当请求到达时，会尝试从令牌桶中取令牌
取到了令牌的请求可以执行
如果桶空了，那么尝试取令牌的请求会被直接丢弃

5.2 为什么是"工业界默认”？

令牌桶既能够将所有的请求平均分布到时间区间内，又能接受服务器能够承受范围内的突发请求——这两点恰好是漏桶和固定窗口都做不到的：

平均限流：长期平均速率 = 令牌生成速率
允许突发：桶里积攒的令牌可以一次性被突发请求用完
平滑降级：桶空了就拒绝，不会让下游被打挂

因此 Guava RateLimiter、Nginx limit_req、AWS API Gateway、Spring Cloud Gateway 等都默认使用令牌桶或它的变体。

5.3 代码实现

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


import time
import threading

class TokenBucketRateLimiter:
 """令牌桶算法：兼顾平滑限流 + 允许突发，是工业界最常用的限流算法"""
 def __init__(self, capacity: int, refill_rate_per_sec: float):
 """
 :param capacity: 桶容量（即最大突发量）
 :param refill_rate_per_sec: 每秒生成的令牌数（平均限流速率）
 """
 self.capacity = capacity
 self.refill_rate = refill_rate_per_sec
 self.tokens = float(capacity) # 初始满桶
 self.last_refill_time = time.time()
 self._lock = threading.Lock()

 def allow(self, cost: float = 1.0) -> bool:
 with self._lock:
 now = time.time()
 # 补充令牌：自上次以来应该生成的令牌数
 elapsed = now - self.last_refill_time
 self.tokens = min(self.capacity, self.tokens + elapsed * self.refill_rate)
 self.last_refill_time = now
 # 取令牌
 if self.tokens >= cost:
 self.tokens -= cost
 return True
 return False

5.4 优缺点

优点	缺点
兼顾平均限流 + 突发	实现比固定/滑动窗口复杂
工业界事实标准	桶容量需要根据业务调优
Guava / Nginx / Sentinel 都内置	分布式实现需要原子操作（Redis + Lua）

六、四大算法对比

维度	固定窗口	滑动窗口	漏桶	令牌桶
时间复杂度	O(1)	O(N)	O(1)	O(1)
空间复杂度	O(1)	O(N)	O(队列长)	O(1)
实现难度	★	★★	★★★	★★★
平滑输出	✗	✗	✓ 绝对平滑	△ 平均平滑、允许突发
允许突发	△ 边界双倍	△	✗ 抹平突发	✓ 可控突发
边界问题	✗ 有	✓ 无	✓ 无	✓ 无
典型应用	简单统计	Cloudflare	消息队列 / 网络整形	API 网关 / Nginx

七、核心要点与常见坑

7.1 核心 N 点

固定窗口有"边界双倍突发"问题——限制 1 秒 5 个，可能 1 秒放 10 个
滑动窗口把窗口细分并滑动，是固定窗口的精准化升级，但内存占用和精度成正比
漏桶强制平滑输出，抹掉突发——空闲时也无法"加速消化"
令牌桶兼顾平均限流 + 可控突发，是工业界事实标准——Guava/Nginx/Sentinel 都用它
限流本质是保护下游——算法选型要回答"下游怕什么"：怕突发 → 漏桶；怕长期过载 → 令牌桶
分布式限流需要共享计数器（Redis + Lua 脚本 / Redis Cell 模块），单机限流直接用进程内限流器即可

7.2 常见 M 个坑

混淆"算法粒度"和"限流维度"——限流可以按 IP / User ID / 接口 / 租户，算法本身和粒度无关
桶容量设得太大——突发可能把下游打挂
桶容量设得太小——失去了"应对正常抖动"的能力
漏桶的"等待"语义被忽略——某些业务根本不能等，直接拒绝更友好
限流后没有兜底——被拒绝的请求要返回友好的错误（429 + Retry-After）
单机限流当成分布式限流用——多机部署时总速率会变成"单机限制 × 机器数"
限流开关没接入监控——出问题时根本不知道是谁在打

八、工业级实践

8.1 Guava `RateLimiter`（单机令牌桶）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// 创建一个每秒生成 5 个令牌的限流器（即平均 200ms 一个）
RateLimiter limiter = RateLimiter.create(5.0);

if (limiter.tryAcquire()) {
 // 拿到令牌，处理请求
 handleRequest();
} else {
 // 没拿到令牌，直接拒绝
 return Response.status(429).build();
}

8.2 Nginx `limit_req`（基于令牌桶）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# 定义一个名为 my_limit 的限流区：
# 10m 共享内存大小
# rate=10r/s 平均 10 个请求/秒
# burst=20 桶容量 20（允许最大 20 个突发）
# nodelay 突发请求不延迟直接处理
limit_req_zone $binary_remote_addr zone=my_limit:10m rate=10r/s;

server {
 location /api/ {
 limit_req zone=my_limit burst=20 nodelay;
 proxy_pass http://backend;
 }
}

8.3 Redis + Lua 分布式令牌桶

单机的 RateLimiter 只对单进程有效，分布式场景需要共享计数器。常见做法是 Redis + Lua 脚本保证原子性：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


-- KEYS[1]: 令牌桶的 key
-- ARGV[1]: 桶容量
-- ARGV[2]: 填充速率（每秒）
-- ARGV[3]: 当前时间戳（秒）
-- ARGV[4]: 请求消耗的令牌数

local capacity = tonumber(ARGV[1])
local rate = tonumber(ARGV[2])
local now = tonumber(ARGV[3])
local cost = tonumber(ARGV[4])

local data = redis.call('HMGET', KEYS[1], 'tokens', 'last_refill')
local tokens = tonumber(data[1]) or capacity
local last_refill = tonumber(data[2]) or now

-- 补充令牌
local elapsed = math.max(0, now - last_refill)
tokens = math.min(capacity, tokens + elapsed * rate)

if tokens >= cost then
 tokens = tokens - cost
 redis.call('HMSET', KEYS[1], 'tokens', tokens, 'last_refill', now)
 redis.call('EXPIRE', KEYS[1], 60) -- 60 秒没访问就清掉
 return 1
else
 redis.call('HMSET', KEYS[1], 'tokens', tokens, 'last_refill', now)
 return 0
end

8.4 选型速查

场景	推荐算法	理由
简单统计、QPS 监控	固定窗口	最简单
API 限流、爬虫限频	滑动窗口	精度高，无边界问题
调用第三方固定速率 API	漏桶	强制平滑，保护合作方
API 网关、Nginx、Sentinel	令牌桶	兼顾平均 + 突发，工业标准
秒杀抢购	令牌桶 + 排队	削峰填谷
分布式系统	令牌桶 + Redis/Lua	多机共享状态