摘要：在当今互联网应用开发领域，高并发访问已经成为常态。对于使用 Spring Boot3 构建的应用系统而言，实现有效的限流机制是保障系统稳定性、可靠性以及用户体验的关键一环。若系统缺乏合理的限流策略，一旦遭遇突发的大量请求，极有可能导致系统资源耗尽，进而出现服务
在当今互联网应用开发领域，高并发访问已经成为常态。对于使用 Spring Boot3 构建的应用系统而言，实现有效的限流机制是保障系统稳定性、可靠性以及用户体验的关键一环。若系统缺乏合理的限流策略，一旦遭遇突发的大量请求，极有可能导致系统资源耗尽，进而出现服务响应缓慢甚至崩溃的严重问题。接下来，让我们深入探讨在 Spring Boot3 中实现限流机制的多种有效方案。
Sentinel 是阿里开源的一款极为强大且灵活的限流熔断组件，在业界广泛应用。它支持控制台可视化配置，这使得开发人员能够直观地对限流规则进行设置和调整；同时具备动态扩展能力，可根据业务需求的变化轻松进行功能拓展；并且提供了多种限流策略，能够满足不同场景下的限流需求。
（一）Sentinel 的常见限流维度
QPS（每秒请求数）限流：通过限制每秒内允许通过的请求数量，防止系统因瞬间高流量请求而不堪重负。例如，将某个接口的 QPS 限制为 100，意味着该接口每秒最多只能处理 100 个请求，超出部分将被限流。
并发线程数限流：控制同时处理请求的线程数量，避免线程过多导致系统资源竞争激烈，影响整体性能。比如，设定某服务的并发线程数为 50，当同时请求该服务的线程数达到 50 时，后续请求将被限流等待。
热点参数限流：针对那些访问频率极高的热门资源或参数进行限流。例如，在电商应用中，对于热门商品的详情页接口，根据商品 ID 这一热点参数进行限流，防止因个别热门商品的高访问量拖垮整个系统。
关联限流：考虑资源之间的依赖关系进行限流控制。例如，服务 A 依赖服务 B，当服务 B 的负载过高时，可以通过关联限流策略，限制对服务 A 的请求，以保护服务 B 的正常运行。
链路限流：对不同入口资源的请求进行独立统计和限流。在复杂的微服务架构中，一个业务请求可能会经过多个不同的入口服务，链路限流可以确保每个入口服务的流量都在可控范围内。
（二）在 Spring Boot3 中集成 Sentinel 的步骤
引入依赖：在项目的 pom.xml 文件中添加以下依赖：
com.alibaba.csp sentinel-core com.alibaba.csp sentinel-annotation-aspectj控制台部署（推荐配置持久化）：首先下载 Sentinel 控制台的 jar 包，然后通过以下命令启动控制台：
java -Dserver.port=8080 -Dcsp.sentinel.dashboard.server=localhost:8080 -jar sentinel-dashboard.jar这里将控制台端口设置为 8080，实际应用中可根据需求调整。同时，为了保证在系统重启等情况下限流规则不丢失，强烈建议配置持久化，可将规则存储到 Nacos 等配置中心。
注解式限流使用：在需要限流的 Controller 方法上使用 @SentinelResource 注解，例如：
@SentinelResource(value = "hello", blockHandler = "handleBlock")@GetMapping("/hello")public String hello { return "Hello Sentinel";}public String handleBlock(BlockException ex) { return "被限流了！";}编程式限流：在业务代码中，可通过编程方式实现更灵活的限流逻辑，例如：
try (Entry entry = SphU.entry("order-service")) { // 业务逻辑} catch (BlockException ex) { // 限流处理逻辑}在这段代码中，通过 SphU.entry 方法尝试进入 “order - service” 资源，如果当前请求未超过限流阈值，则可以正常执行 try 块中的业务逻辑；若超出阈值，将捕获 BlockException 异常，进入 catch 块执行限流处理逻辑
配合 Nacos 实现规则持久化：将 Sentinel 的限流规则存储到 Nacos 配置中心，实现规则的集中管理和动态更新。在 Nacos 中配置好相关规则后，Sentinel 控制台可以实时获取并应用这些规则，即使 Sentinel 服务重启，规则也不会丢失。
自定义资源路径解析器，按用户或 IP 限流：通过自定义资源路径解析器，可以实现根据用户或 IP 地址进行更细粒度的限流。例如：
WebCallbackManager.setUrlCleaner(url -> { // 统一URL资源名，避免path变量被当成不同资源 return url.replaceAll("/user/\\d+", "/user/*");});优点：功能强大，提供了丰富的限流维度和灵活的配置方式；集成简单，在 Spring Boot3 项目中只需引入相关依赖并进行简单配置即可使用；支持动态化调整限流规则，无需重启应用即可实时生效，非常适合应对业务流量的动态变化。
缺点：依赖 Sentinel 控制台，需要额外部署和维护控制台服务；为了保证规则的持久化和可靠性，需要配置持久化存储，增加了一定的系统复杂度。
在微服务架构中，单节点的限流方案无法满足多实例部署的需求 —— 若每个服务实例单独限流，可能因流量分配不均导致整体超出预期负载，而 Redisson 基于 Redis 的分布式特性，能实现跨实例的统一限流，尤其适合 Spring Boot3 集群环境。
redisson 限流的核心原理：令牌桶算法的分布式实现
Redisson 的RRateLimiter组件底层采用令牌桶算法，其核心逻辑如下：
系统按固定速率向 “令牌桶” 中投放令牌，例如每秒投放 100 个令牌；每个请求到达时需从桶中获取 1 个令牌，获取成功则允许访问，获取失败则触发限流；若令牌桶已满，多余令牌会被丢弃；若桶中无令牌，请求需等待或直接拒绝（可配置）。与单机令牌桶不同，Redisson 通过 Redis 的原子操作（如INCR、EXPIRE）确保多实例下令牌计数的一致性，避免 “超发” 或 “漏判” 问题。
Spring Boot3 集成 Redisson 的详细步骤
步骤 1：引入依赖
在pom.xml中添加 Redisson 的 Spring Boot Starter 依赖（需注意与 Spring Boot3 版本兼容，此处推荐 3.23.3 版本，经实测适配 Spring Boot3.0+）：
org.Redisson redisson-spring-boot-starter 3.23.3 org.springframework.boot spring-boot-starter-web步骤 2：配置 Redis 连接
在application.yml中配置 Redis 地址、密码等信息，Redisson 会自动读取配置并创建客户端：
spring: redis: host: 127.0.0.1 # 你的Redis地址 port: 6379 # Redis端口 password: 123456 # Redis密码（若无则省略） database: 0 # Redis数据库索引redisson: singleServerConfig: connectionMinimumIdleSize: 5 # 最小空闲连接数 connectionPoolSize: 10 # 连接池大小 idleConnectionTimeout: 10000 # 空闲连接超时时间（毫秒）步骤 3：自定义限流注解与切面
为了让限流逻辑更灵活可复用，我们通过自定义注解@DistributedRateLimit标记需要限流的接口，再结合 Spring AOP 实现切面拦截：
3.1 定义限流注解
import java.lang.annotation.*;/** * 分布式限流注解 */@Target({ElementType.METHOD}) // 仅作用于方法@Retention(RetentionPolicy.RUNTIME) // 运行时生效@Documentedpublic @interface DistributedRateLimit { /** * 限流key前缀（默认取方法全路径名） */ String keyPrefix default ""; /** * 每秒允许的请求数（令牌生成速率） */ int rate default 10; /** * 令牌桶容量（最大缓存令牌数） */ int capacity default 20; /** * 限流提示信息 */ String message default "当前请求人数过多，请稍后再试！";}3.2 实现 AOP 切面
通过切面拦截被@DistributedRateLimit标记的方法，在方法执行前调用 Redisson 的tryAcquire方法判断是否允许访问：
import org.aspectj.lang.ProceedingJoinPoint;import org.aspectj.lang.annotation.Around;import org.aspectj.lang.annotation.Aspect;import org.aspectj.lang.reflect.MethodSignature;import org.redisson.api.RRateLimiter;import org.redisson.api.RateType;import org.redisson.api.RedissonClient;import org.springframework.beans.factory.annotation.Autowired;import org.springframework.stereotype.Component;import java.lang.reflect.Method;@Aspect@Componentpublic class DistributedRateLimitAspect { @Autowired private RedissonClient redissonClient; @Around("@annotation(com.yourpackage.DistributedRateLimit)") // 替换为你的注解全路径 public Object rateLimitAround(ProceedingJoinPoint joinPoint) throws Throwable { // 1. 获取方法上的限流注解 MethodSignature signature = (MethodSignature) joinPoint.getSignature; Method method = signature.getMethod; DistributedRateLimit rateLimit = method.getAnnotation(DistributedRateLimit.class); // 2. 构建限流key（默认：接口全路径名，可按需求添加IP、用户ID等维度） String key = rateLimit.keyPrefix.isEmpty ? method.getDeclaringClass.getName + "." + method.getName : rateLimit.keyPrefix; // 3. 获取Redisson的RateLimiter实例 RRateLimiter rateLimiter = redissonClient.getRateLimiter(key); // 配置限流规则：速率（rate）、容量（capacity）、速率类型（OVERALL：全局限流） rateLimiter.trySetRate(RateType.OVERALL, rateLimit.rate, 1, java.util.concurrent.TimeUnit.SECONDS); // 4. 尝试获取令牌（1秒内等待，超时则拒绝） boolean canAccess = rateLimiter.tryAcquire(1, 1, java.util.concurrent.TimeUnit.SECONDS); if (!canAccess) { // 限流触发：可根据项目需求返回JSON、抛自定义异常等 throw new RuntimeException(rateLimit.message); } // 5. 获取令牌成功，执行原方法 return joinPoint.proceed; }}步骤 4：在接口中使用限流注解
在需要限流的 Controller 接口上添加@DistributedRateLimit注解，配置具体的限流参数：
import org.springframework.web.bind.annotation.GetMapping;import org.springframework.web.bind.annotation.requestMapping;import org.springframework.web.bind.annotation.RestController;@RestController@RequestMapping("/api/order")public class OrderController { /** * 订单提交接口：每秒允许15个请求，令牌桶容量30 */ @GetMapping("/submit") @DistributedRateLimit(rate = 15, capacity = 30, message = "订单提交过于频繁，请1秒后重试！") public String submitOrder { // 模拟订单提交逻辑 return "订单提交成功！"; }}Redisson 限流的优势与注意事项
优势：
分布式一致性：基于 Redis 实现，多服务实例共享限流状态，避免 “单机限流失效” 问题；
动态调整：支持通过 Redisson 客户端动态修改限流规则（如rateLimiter.setRate），无需重启服务；
高可用性：若 Redis 采用集群模式（主从 + 哨兵 / Redis Cluster），可避免单点故障导致限流失效。
注意事项：
Redis 性能依赖：限流逻辑强依赖 Redis 响应速度，若 Redis 延迟过高，可能导致接口响应变慢，建议 Redis 部署在与服务同一局域网；
key 设计维度：需根据业务场景设计限流 key（如按接口、用户 ID、IP 地址），避免 “一刀切” 限流（例如管理员账号无需限流）；
异常处理：需考虑 Redis 连接失败的场景，可配置 “降级策略”（如临时允许不限流），避免因 Redis 故障导致服务不可用。
若项目无需 Redisson 的复杂功能，仅需简单的接口限流（如按 IP 限流），可通过 Spring MVC 的HandlerInterceptor结合 Redis 实现轻量级方案，该方案灵活性高，且无需引入额外组件。
核心逻辑：Redis 计数器 + 过期时间
基于 “固定时间窗口算法”，核心思路如下：
为每个限流维度（如 IP + 接口）生成 Redis key，例如rate_limit:192.168.1.1:/api/user/list；每次请求到达时，通过 Redis 的INCR命令对 key 进行计数，同时设置 key 的过期时间（如 60 秒）；若计数超过预设阈值（如 60 秒内允许 100 次请求），则拦截请求，返回限流提示；反之则放行。具体实现步骤
步骤 1：自定义限流注解（标记接口）
import java.lang.annotation.*;/** * 接口限流注解（用于拦截器） */@Target({ElementType.METHOD})@Retention(RetentionPolicy.RUNTIME)@Documentedpublic @interface ApiRateLimit { /** * 时间窗口（秒） */ int windowSeconds default 60; /** * 时间窗口内最大请求数 */ int maxRequests default 100; /** * 限流提示 */ String message default "请求过于频繁，请稍后再试！";}步骤 2：实现 HandlerInterceptor 拦截器
import jakarta.servlet.http.HttpServletRequest;import jakarta.servlet.http.HttpServletResponse;import org.springframework.data.redis.core.StringRedisTemplate;import org.springframework.stereotype.Component;import org.springframework.web.method.HandlerMethod;import org.springframework.web.servlet.HandlerInterceptor;import java.io.IOException;import java.io.PrintWriter;import java.util.concurrent.TimeUnit;@Componentpublic class ApiRateLimitInterceptor implements HandlerInterceptor { private final StringRedisTemplate stringRedisTemplate; // 构造注入StringRedisTemplate（Spring Boot3自动配置） public ApiRateLimitInterceptor(StringRedisTemplate stringRedisTemplate) { this.stringRedisTemplate = stringRedisTemplate; } @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 1. 判断handler是否为Controller方法（排除静态资源等） if (!(handler instanceof HandlerMethod handlerMethod)) { return true; // 非Controller方法，直接放行 } // 2. 获取方法上的限流注解 ApiRateLimit rateLimit = handlerMethod.getMethodAnnotation(ApiRateLimit.class); if (rateLimit == null) { return true; // 无注解，直接放行 } // 3. 生成限流key（IP + 接口路径） String clientIp = getClientIp(request); // 获取客户端IP String requestUri = request.getRequestURI; String limitKey = "rate_limit:" + clientIp + ":" + requestUri; // 4. Redis计数：自增1，若key不存在则创建并设置过期时间 Long currentCount = stringRedisTemplate.opsForValue.increment(limitKey); if (currentCount == 1) { // 首次计数，设置过期时间（与时间窗口一致） stringRedisTemplate.expire(limitKey, rateLimit.windowSeconds, TimeUnit.SECONDS); } // 5. 判断是否超出限流阈值 if (currentCount > rateLimit.maxRequests) { // 拦截请求：返回JSON格式的限流提示 response.setContentType("application/json;charset=UTF-8"); response.setStatus(HttpServletResponse.SC_TOO_MANY_REQUESTS); // 429状态码 PrintWriter writer = response.getWriter; writer.write("{\"code\":429,\"message\":\"" + rateLimit.message + "\"}"); writer.flush; writer.close; return false; // 拦截请求 } // 6. 未超出阈值，放行 return true; } /** * 获取客户端真实IP（处理代理场景，如Nginx） */ private String getClientIp(HttpServletRequest request) { String ip = request.getHeader("X-Forwarded-For"); if (ip == null || ip.isEmpty || "unknown".equalsIgnoreCase(ip)) { ip = request.getHeader("Proxy-Client-IP"); } if (ip == null || ip.isEmpty || "unknown".equalsIgnoreCase(ip)) { ip = request.getHeader("WL-Proxy-Client-IP"); } if (ip == null || ip.isEmpty || "unknown".equalsIgnoreCase(ip)) { ip = request.getRemoteAddr; } // 若为多代理，取第一个非unknown的IP return ip != null ? ip.split(",")[0].trim : ip; }}步骤 3：注册拦截器
在 Spring Boot3 中，通过WebMvcConfigurer注册拦截器，指定需要拦截的接口路径：
import org.springframework.context.annotation.Configuration;import org.springframework.web.servlet.config.annotation.InterceptorRegistry;import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;@Configurationpublic class WebMvcConfig implements WebMvcConfigurer { private final ApiRateLimitInterceptor rateLimitInterceptor; public WebMvcConfig(ApiRateLimitInterceptor rateLimitInterceptor) { this.rateLimitInterceptor = rateLimitInterceptor; } @Override public void addInterceptors(InterceptorRegistry registry) { // 注册限流拦截器，拦截所有/api/**路径的接口 registry.addInterceptor(rateLimitInterceptor) .addPathPatterns("/api/**") .excludePathPatterns("/api/login"); // 排除无需限流的接口（如登录） }}步骤 4：在接口中使用注解
import org.springframework.web.bind.annotation.GetMapping;import org.springframework.web.bind.annotation.RequestMapping;import org.springframework.web.bind.annotation.RestController;@RestController@RequestMapping("/api/user")public class UserController { /** * 用户列表接口：60秒内允许50次请求（按IP限流） */ @GetMapping("/list") @ApiRateLimit(windowSeconds = 60, maxRequests = 50, message = "获取用户列表过于频繁，请1分钟后重试！") public String getUserList { // 模拟查询用户列表逻辑 return "[{\"id\":1,\"name\":\"张三\"},{\"id\":2,\"name\":\"李四\"}]"; }}该方案的局限性与优化方向
局限性：
固定时间窗口缺陷：可能出现 “边界溢出” 问题（例如 60 秒窗口的最后 1 秒和下一个窗口的第 1 秒，共允许 2 倍阈值的请求）；
不支持分布式：若服务多实例部署，且每个实例单独计数（基于 IP），可能因 IP 哈希不均导致部分实例过载；
功能单一：无动态调整、控制台监控等功能，仅适合简单场景。
优化方向：
改用滑动时间窗口：通过 Redis 的ZSet存储请求时间戳，计算滑动窗口内的请求数，解决边界溢出问题；
引入 Redis 分布式锁：若需多实例共享计数，可通过SET NX实现分布式锁，确保计数一致性；
增加监控告警：结合 Prometheus+Grafana 监控限流次数，当触发限流时发送告警（如钉钉、邮件）。
在 Spring Boot3 项目中，Sentinel、Redisson、拦截器 + Redis 是实现限流的主流方案，三者各有优劣，需根据业务场景选择：
方案核心优势适用场景缺点Sentinel功能全面（限流 + 熔断 + 监控）、控制台可视化微服务架构、需精细化流量控制（如按接口、用户）需引入额外组件，学习成本较高Redisson分布式一致性强、支持动态调整集群部署、需跨实例统一限流（如全局限流）依赖 Redis 性能，无原生监控控制台拦截器 + Redis轻量级、自定义灵活、无额外依赖简单场景（如按 IP 限流）、单体应用不支持复杂规则，无分布式一致性保障选型建议：
若项目是微服务架构，且需同时实现限流、熔断、降级（如防止下游服务故障影响上游），优先选择Sentinel；
若项目是集群部署，仅需分布式限流，且已使用 Redis，优先选择Redisson（无需额外组件）；
若项目是单体应用，仅需简单的 IP / 接口限流，优先选择拦截器 + Redis（开发成本低）。
来源：从程序员到架构师一点号
