目录
👋前言
🍸一、应用场景
🍻二、 代码实现
🍹三、扩展
🍸四、章末
👋前言
小伙伴们大家好，上次本地实操了下针对百万级数据量如何快速排序、指定条件获取等，文章内容包括：SpringBoot 中如何集成 redis、多线程批量创建测试数据、缓存预热等可以参考下，文章链接如下：
【SpringBoot】⭐️整合 Redis 实现百万级数据实时排序_springboot redis 排序-CSDN博客
这篇文章将本地实现如何控制接口的负载，也就是如何指定一段时间内接口可以接收的请求上限
🍸一、应用场景
什么场景下需要考虑接口的负载，简单讲就是那些访问量过大的接口如果会影响系统的运行则需要提前准备负载规则，避免过载
单体应用：
单体项目中，某些关键接口可以使用限流，避免系统崩溃（比如，处理大量数据的接口，如果业务操作中会将大量数据加载到内存，那么该接口就需要限流，避免高并发情况下，导致内存溢出）
第三方API：
如果对接的部分 api 本身有限流策略限制，那么在自己应用中限流，可以更好的管理调用频率，避免触发对方的限流机制
API网关：
微服务架构中，可以在整个系统的入口处进行限流，控制进入系统的请求频率，放置后端服务过载
...
针对以上场景，可以提前准备限流规则，具体的工具有很多，比如阿里的 sentinel 限流工具，支持各种策略，可以参考之前的文章：
【Sentinel的限流使用】⭐️SpringCloud整合Sentinel实现Api的限流_sentinel api管理-CSDN博客
但是使用 Sentinel 实现更偏向于 SpringCloud 整合，因为是一个单独的服务，本地使用的话需要先启动 sentinel 服务，然后在自己项目中才可以正常使用；这里也可以使用另一个工具，就是标题中的 Resilience4j ，是一个轻量级的容错库，用于在 Java 应用中实现各种常见的失败模式，比如超时、请求限制、重试等。
🍻二、 代码实现
2.1 添加依赖
<!-- Resilience4j Spring Boot2 --><dependency><groupId>io.github.resilience4j</groupId><artifactId>resilience4j-spring-boot2</artifactId><version>1.7.0</version></dependency><dependency><groupId>io.github.resilience4j</groupId><artifactId>resilience4j-retry</artifactId><version>1.7.0</version></dependency>2.2 配置限流规则
如下，这里的 exampleRateLimiter 是自定义的限制器（10秒内最大请求为3）
resilience4j.ratelimiter:instances:exampleRateLimiter:limitForPeriod: 3limitRefreshPeriod: 10000mstimeoutDuration: 500ms2.3 限流注解使用
创建一个请求控制器类，测试下自定义的限制器是否正常
这里指定了重定向方法，也就是被限流的请求会被重定向到指定的方法，返回对应的信息
@RestController
@RequestMapping("/testRate")
@Slf4j
public class RateLimitController {@GetMapping("/testLimit")@RateLimiter(name = "exampleRateLimiter",fallbackMethod = "handleFallBack")public String testLimit(){log.info("allow operating");return "success";}public String handleFallBack( Throwable throwable){log.error(" callBack method called due to rateLimiting ",throwable);return "request limited, please try later";}}2.4 测试
如图，目前的规则是10秒内允许进入三次请求，剩下的执行拒绝方法；postman 模拟下请求即可,快速点击几次，看下控台日志，进入了三个请求，剩余请求都被拒绝，并且执行了重定向的方法，说明自定义的限流工具生效
🍹三、扩展
到这里基于 Resilience4j 的限流方式已经实现了， 这个工具还可以支持自动重试，可以指定重试的类型（遇到指定的类型错误后，可以自动重试），来试下
3.1 自定义重试机制
跟自定义限制器一样，也是在配置文件中添加对应配置，这里是自定义了一个遇到 RuntimeException 异常的重试机制，会进行三次重试，每次重试间隔1秒，三次仍然出错，则直接返回
resilience4j.retry:instances:testRetry:maxAttempts: 3 # 最大重试次数waitDuration: 1000ms # 每次重试的间隔retryExceptions:- java.lang.RuntimeException # 针对 RuntimeException 进行重试3.2 重试注解使用
这里指定了重试机制的名称，并且指定了重定向方法
方法体较简单，每次请求会随机生成一个随机数，大于 0.5 则抛出 RuntimeException 异常,小于的话则正常返回提示
@GetMapping("/testRetry")@Retry(name = "testRetry", fallbackMethod = "handleFallBack")public String testRetry() {return externalServiceCall();}public String externalServiceCall() {// 模拟外部服务调用失败double random = Math.random();if (random > 0.5) {log.error("currentNum {} ,service call failed, retrying...",random);throw new RuntimeException("service failure");}log.info("currentNum {},service call succeeded");return "success : " + random;}3.3 测试
模拟一个请求，测试结果如下：
重试了三次，每次间隔一秒，还是没有通过，然后进行了方法重定向
🍸四、章末
以上是基于 Resilience4j 依赖引入的方式实现，相比于 sentinel 工具实现简单，但是使用可能不如其方便，因为 sentinel 可以随时调整配置，并且对代码的侵入性不是很强；
另外就是这种也可以自己实现，比如使用 redis 统计对应接口的指定时间内访问次数，超过了指定次数就拦截，这里就不重复造轮子了
文章到这里就结束了~
