SpringBoot限制接口访问频率
Posted 码老思
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了SpringBoot限制接口访问频率相关的知识，希望对你有一定的参考价值。
最近在基于SpringBoot做一个面向普通用户的系统，为了保证系统的稳定性，防止被恶意攻击，我想控制用户访问每个接口的频率。为了实现这个功能，可以设计一个annotation，然后借助AOP在调用方法之前检查当前ip的访问频率，如果超过设定频率，直接返回错误信息。
常见的错误设计
在开始介绍具体实现之前，我先列举几种我在网上找到的几种常见错误设计。
1. 固定窗口
有人设计了一个在每分钟内只允许访问1000次的限流方案，如下图01:00s-02:00s之间只允许访问1000次，这种设计最大的问题在于，请求可能在01:59s-02:00s之间被请求1000次，02:00s-02:01s之间被请求了1000次，这种情况下01:59s-02:01s间隔0.02s之间被请求2000次，很显然这种设计是错误的。
2. 缓存时间更新错误
我在研究这个问题的时候，发现网上有一种很常见的方式来进行限流，思路是基于redis，每次有用户的request进来，就会去以用户的ip和request的url为key去判断访问次数是否超标，如果有就返回错误，否则就把redis中的key对应的value加1，并重新设置key的过期时间为用户指定的访问周期。核心代码如下：
// core logic
int limit = accessLimit.limit();
long sec = accessLimit.sec();
String key = IPUtils.getIpAddr(request) + request.getRequestURI();
Integer maxLimit =null;
Object value =redisService.get(key);
if(value!=null && !value.equals(""))
maxLimit = Integer.valueOf(String.valueOf(value));
if (maxLimit == null)
redisService.set(key, "1", sec);
else if (maxLimit < limit)
Integer i = maxLimit+1;
redisService.set(key, i.toString(), sec);
else
throw new BusinessException(500,"请求太频繁!");
// redis related
public boolean set(final String key, Object value, Long expireTime)
boolean result = false;
try
ValueOperations<Serializable, Object> operations = redisTemplate.opsForValue();
operations.set(key, value);
redisTemplate.expire(key, expireTime, TimeUnit.SECONDS);
result = true;
catch (Exception e)
e.printStackTrace();
return result;
这里面很大的问题，就是每次都会更新key的缓存过期时间，这样相当于变相延长了每个计数周期， 可能我们想控制用户一分钟内只能访问5次，但是如果用户在前一分钟只访问了三次，后一分钟访问了三次，在上面的实现里面，很可能在第6次访问的时候返回错误，但这样是有问题的，因为用户确实在两分钟内都没有超过对应的访问频率阈值。
关于key的刷新这块，可以参看redis官方文档，每次refreh都会更新key的过期时间。
基于滑动窗口的正确设计
指定时间T内，只允许发生N次。我们可以将这个指定时间T，看成一个滑动时间窗口（定宽）。我们采用Redis的zset基本数据类型的score来圈出这个滑动时间窗口。在实际操作zset的过程中，我们只需要保留在这个滑动时间窗口以内的数据，其他的数据不处理即可。
比如在上面的例子里面，假设用户的要求是60s内访问频率控制为3次。那么我永远只会统计当前时间往前倒数60s之内的访问次数，随着时间的推移，整个窗口会不断向前移动，窗口外的请求不会计算在内，保证了永远只统计当前60s内的request。
为什么选择Redis zset ？
为了统计固定时间区间内的访问频率，如果是单机程序，可能采用concurrentHashMap就够了，但是如果是分布式的程序，我们需要引入相应的分布式组件来进行计数统计，而Redis zset刚好能够满足我们的需求。
Redis zset（有序集合）中的成员是有序排列的，它和 set 集合的相同之处在于，集合中的每一个成员都是字符串类型，并且不允许重复；而它们最大区别是，有序集合是有序的，set 是无序的，这是因为有序集合中每个成员都会关联一个 double（双精度浮点数）类型的 score (分数值)，Redis 正是通过 score 实现了对集合成员的排序。
Redis 使用以下命令创建一个有序集合：
ZADD key score member [score member ...]
这里面有三个重要参数，
- key：指定一个键名；
- score：分数值，用来描述 member，它是实现排序的关键；
- member：要添加的成员（元素）。
当 key 不存在时，将会创建一个新的有序集合，并把分数/成员（score/member）添加到有序集合中；当 key 存在时，但 key 并非 zset 类型，此时就不能完成添加成员的操作，同时会返回一个错误提示。
在我们这个场景里面，key就是用户ip+request uri，score直接用当前时间的毫秒数表示，至于member不重要，可以也采用和score一样的数值即可。
限流过程是怎么样的？
整个流程如下：
- 首先用户的请求进来，将用户ip和uri组成key，timestamp为value，放入zset
- 更新当前key的缓存过期时间，这一步主要是为了定期清理掉冷数据，和上面我提到的常见错误设计2中的意义不同。
- 删除窗口之外的数据记录。
- 统计当前窗口中的总记录数。
- 如果记录数大于阈值，则直接返回错误，否则正常处理用户请求。
基于SpringBoot和AOP的限流
这一部分主要介绍具体的实现逻辑。
定义注解和处理逻辑
首先是定义一个注解，方便后续对不同接口使用不同的限制频率。
/**
* 接口访问频率注解，默认一分钟只能访问5次
*/
@Documented
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface RequestLimit
// 限制时间 单位：秒(默认值：一分钟）
long period() default 60;
// 允许请求的次数(默认值：5次）
long count() default 5;
在实现逻辑这块，我们定义一个切面函数，拦截用户的request，具体实现流程和上面介绍的限流流程一致，主要涉及到redis zset的操作。
@Aspect
@Component
@Log4j2
public class RequestLimitAspect
@Autowired
RedisTemplate redisTemplate;
// 切点
@Pointcut("@annotation(requestLimit)")
public void controllerAspect(RequestLimit requestLimit)
@Around("controllerAspect(requestLimit)")
public Object doAround(ProceedingJoinPoint joinPoint, RequestLimit requestLimit) throws Throwable
// get parameter from annotation
long period = requestLimit.period();
long limitCount = requestLimit.count();
// request info
String ip = RequestUtil.getClientIpAddress();
String uri = RequestUtil.getRequestUri();
String key = "req_limit_".concat(uri).concat(ip);
ZSetOperations zSetOperations = redisTemplate.opsForZSet();
// add current timestamp
long currentMs = System.currentTimeMillis();
zSetOperations.add(key, currentMs, currentMs);
// set the expiration time for the code user
redisTemplate.expire(key, period, TimeUnit.SECONDS);
// remove the value that out of current window
zSetOperations.removeRangeByScore(key, 0, currentMs - period * 1000);
// check all available count
Long count = zSetOperations.zCard(key);
if (count > limitCount)
log.error("接口拦截： 请求超过限制频率【次/s】,IP为", uri, limitCount, period, ip);
throw new AuroraRuntimeException(ResponseCode.TOO_FREQUENT_VISIT);
// execute the user request
return joinPoint.proceed();
使用注解进行限流控制
这里我定义了一个接口类来做测试，使用上面的annotation来完成限流，每分钟允许用户访问3次。
@Log4j2
@RestController
@RequestMapping("/user")
public class UserController
@GetMapping("/test")
@RequestLimit(count = 3)
public GenericResponse<String> testRequestLimit()
log.info("current time: " + new Date());
return new GenericResponse<>(ResponseCode.SUCCESS);
我接着在不同机器上，访问该接口，可以看到不同机器的限流是隔离的，并且每台机器在周期之内只能访问三次，超过后，需要等待一定时间才能继续访问，达到了我们预期的效果。
2023-05-21 11:23:15.733 INFO 99636 --- [nio-8080-exec-1] c.v.c.a.api.controller.UserController : current time: Sun May 21 11:23:15 CST 2023
2023-05-21 11:23:21.848 INFO 99636 --- [nio-8080-exec-3] c.v.c.a.api.controller.UserController : current time: Sun May 21 11:23:21 CST 2023
2023-05-21 11:23:23.044 INFO 99636 --- [nio-8080-exec-4] c.v.c.a.api.controller.UserController : current time: Sun May 21 11:23:23 CST 2023
2023-05-21 11:23:25.920 ERROR 99636 --- [nio-8080-exec-5] c.v.c.a.annotation.RequestLimitAspect : 接口拦截：/user/test 请求超过限制频率【3次/60s】,IP为0:0:0:0:0:0:0:1
2023-05-21 11:23:28.761 ERROR 99636 --- [nio-8080-exec-6] c.v.c.a.annotation.RequestLimitAspect : 接口拦截：/user/test 请求超过限制频率【3次/60s】,IP为0:0:0:0:0:0:0:1
2023-05-21 11:24:12.207 INFO 99636 --- [io-8080-exec-10] c.v.c.a.api.controller.UserController : current time: Sun May 21 11:24:12 CST 2023
2023-05-21 11:24:19.100 INFO 99636 --- [nio-8080-exec-2] c.v.c.a.api.controller.UserController : current time: Sun May 21 11:24:19 CST 2023
2023-05-21 11:24:20.117 INFO 99636 --- [nio-8080-exec-1] c.v.c.a.api.controller.UserController : current time: Sun May 21 11:24:20 CST 2023
2023-05-21 11:24:21.146 ERROR 99636 --- [nio-8080-exec-3] c.v.c.a.annotation.RequestLimitAspect : 接口拦截：/user/test 请求超过限制频率【3次/60s】,IP为192.168.31.114
2023-05-21 11:24:26.779 ERROR 99636 --- [nio-8080-exec-4] c.v.c.a.annotation.RequestLimitAspect : 接口拦截：/user/test 请求超过限制频率【3次/60s】,IP为192.168.31.114
2023-05-21 11:24:29.344 ERROR 99636 --- [nio-8080-exec-5] c.v.c.a.annotation.RequestLimitAspect : 接口拦截：/user/test 请求超过限制频率【3次/60s】,IP为192.168.31.114
欢迎关注公众号【码老思】，只讲最通俗易懂的原创技术干货。
秒杀系统之「抢购接口隐藏」 + 「单用户限制频率」
本文公众号来源：后端技术漫谈
作者：蛮三刀把刀
本文已收录至我的
GitHub
本篇主要讲解秒杀系统中，关于抢购（下单）接口相关的单用户防刷措施，主要说两块内容：
抢购接口隐藏
单用户限制频率（单位时间内限制访问次数）
当然，这两个措施放在任何系统中都有用，严格来说并不是秒杀系统独特的设计，所以今天的内容也会比较的通用。
此外，我做了一张流程图，描述了目前我们实现的秒杀接口下单流程：
妈妈再也不用担心只会看文章不会实现啦：
https://github.com/qqxx6661/miaosha
抢购接口隐藏
在前两篇文章的介绍下，我们完成了防止超卖商品和抢购接口的限流，已经能够防止大流量把我们的服务器直接搞炸，这篇文章中，我们要开始关心一些细节问题。
对于稍微懂点电脑的，又会动歪脑筋的人来说，点击F12打开浏览器的控制台，就能在点击抢购按钮后，获取我们抢购接口的链接。（手机APP等其他客户端可以抓包来拿到）
一旦坏蛋拿到了抢购的链接，只要稍微写点爬虫代码，模拟一个抢购请求，就可以不通过点击下单按钮，直接在代码中请求我们的接口，完成下单。所以就有了成千上万的薅羊毛军团，写一些脚本抢购各种秒杀商品。
他们只需要在抢购时刻的000毫秒，开始不间断发起大量请求，觉得比大家在APP上点抢购按钮要快，毕竟人的速度又极限，更别说APP说不定还要经过几层前端验证才会真正发出请求。
所以我们需要将抢购接口进行隐藏，抢购接口隐藏（接口加盐）的具体做法：
每次点击秒杀按钮，先从服务器获取一个秒杀验证值（接口内判断是否到秒杀时间）。
用户请求秒杀商品的时候，要带上秒杀验证值进行校验。
大家先停下来仔细想想，通过这样的办法，能够防住通过脚本刷接口的人吗？
能，也不能。
可以防住的是直接请求接口的人，但是只要坏蛋们把脚本写复杂一点，先去请求一个验证值，再立刻请求抢购，也是能够抢购成功的。
不过坏蛋们请求验证值接口，也需要在抢购时间开始后，才能请求接口拿到验证值，然后才能申请抢购接口。理论上来说在访问接口的时间上受到了限制，并且我们还能通过在验证值接口增加更复杂的逻辑，让获取验证值的接口并不快速返回验证值，进一步拉平普通用户和坏蛋们的下单时刻。所以接口加盐还是有用的！
下面我们就实现一种简单的加盐接口代码，抛砖引玉。
代码逻辑实现
代码还是使用之前的项目，我们在其上面增加两个接口：
获取验证值接口
携带验证值下单接口
由于之前我们只有两个表，一个stock表放库存商品，一个stockOrder订单表，放订购成功的记录。但是这次涉及到了用户，所以我们新增用户表，并且添加一个用户张三。并且在订单表中，不仅要记录商品id，同时要写入用户id。
整个SQL结构如下，讲究一个简洁，暂时不加入别的多余字段：
-- ----------------------------
-- Table structure for stock
-- ----------------------------
DROP TABLE IF EXISTS `stock`;
CREATE TABLE `stock` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(50) NOT NULL DEFAULT '' COMMENT '名称',
`count` int(11) NOT NULL COMMENT '库存',
`sale` int(11) NOT NULL COMMENT '已售',
`version` int(11) NOT NULL COMMENT '乐观锁，版本号',
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8;
-- ----------------------------
-- Records of stock
-- ----------------------------
INSERT INTO `stock` VALUES ('1', 'iphone', '50', '0', '0');
INSERT INTO `stock` VALUES ('2', 'mac', '10', '0', '0');
-- ----------------------------
-- Table structure for stock_order
-- ----------------------------
DROP TABLE IF EXISTS `stock_order`;
CREATE TABLE `stock_order` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`sid` int(11) NOT NULL COMMENT '库存ID',
`name` varchar(30) NOT NULL DEFAULT '' COMMENT '商品名称',
`user_id` int(11) NOT NULL DEFAULT '0',
`create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '创建时间',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
-- ----------------------------
-- Records of stock_order
-- ----------------------------
-- ----------------------------
-- Table structure for user
-- ----------------------------
DROP TABLE IF EXISTS `user`;
CREATE TABLE `user` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`user_name` varchar(255) NOT NULL DEFAULT '',
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8mb4;
-- ----------------------------
-- Records of user
-- ----------------------------
INSERT INTO `user` VALUES ('1', '张三');
SQL文件在开源代码里也放了，不用担心。
获取验证值接口
该接口要求传用户id和商品id，返回验证值，并且该验证值
Controller中添加方法：
/**
* 获取验证值
* @return
*/
@RequestMapping(value = "/getVerifyHash", method = {RequestMethod.GET})
@ResponseBody
public String getVerifyHash(@RequestParam(value = "sid") Integer sid,
@RequestParam(value = "userId") Integer userId) {
String hash;
try {
hash = userService.getVerifyHash(sid, userId);
} catch (Exception e) {
LOGGER.error("获取验证hash失败，原因：[{}]", e.getMessage());
return "获取验证hash失败";
}
return String.format("请求抢购验证hash值为：%s", hash);
}
UserService中添加方法：
@Override
public String getVerifyHash(Integer sid, Integer userId) throws Exception {
// 验证是否在抢购时间内
LOGGER.info("请自行验证是否在抢购时间内");
// 检查用户合法性
User user = userMapper.selectByPrimaryKey(userId.longValue());
if (user == null) {
throw new Exception("用户不存在");
}
LOGGER.info("用户信息：[{}]", user.toString());
// 检查商品合法性
Stock stock = stockService.getStockById(sid);
if (stock == null) {
throw new Exception("商品不存在");
}
LOGGER.info("商品信息：[{}]", stock.toString());
// 生成hash
String verify = SALT + sid + userId;
String verifyHash = DigestUtils.md5DigestAsHex(verify.getBytes());
// 将hash和用户商品信息存入redis
String hashKey = CacheKey.HASH_KEY.getKey() + "_" + sid + "_" + userId;
stringRedisTemplate.opsForValue().set(hashKey, verifyHash, 3600, TimeUnit.SECONDS);
LOGGER.info("Redis写入：[{}] [{}]", hashKey, verifyHash);
return verifyHash;
}
一个Cache常量枚举类CacheKey：
package cn.monitor4all.miaoshadao.utils;
public enum CacheKey {
HASH_KEY("miaosha_hash"),
LIMIT_KEY("miaosha_limit");
private String key;
private CacheKey(String key) {
this.key = key;
}
public String getKey() {
return key;
}
}
代码解释：
可以看到在Service中，我们拿到用户id和商品id后，会检查商品和用户信息是否在表中存在，并且会验证现在的时间（我这里为了简化，只是写了一行LOGGER，大家可以根据需求自行实现）。在这样的条件过滤下，才会给出hash值。并且将Hash值写入了Redis中，缓存3600秒（1小时），如果用户拿到这个hash值一小时内没下单，则需要重新获取hash值。
下面又到了动小脑筋的时间了，想一下，这个hash值，如果每次都按照商品+用户的信息来md5，是不是不太安全呢。毕竟用户id并不一定是用户不知道的（就比如我这种用自增id存储的，肯定不安全），而商品id，万一也泄露了出去，那么坏蛋们如果再知到我们是简单的md5，那直接就把hash算出来了！
在代码里，我给hash值加了个前缀，也就是一个salt（盐），相当于给这个固定的字符串撒了一把盐，这个盐是HASH_KEY("miaosha_hash")，写死在了代码里。这样黑产只要不猜到这个盐，就没办法算出来hash值。
这也只是一种例子，实际中，你可以把盐放在其他地方， 并且不断变化，或者结合时间戳，这样就算自己的程序员也没法知道hash值的原本字符串是什么了。
携带验证值下单接口
用户在前台拿到了验证值后，点击下单按钮，前端携带着特征值，即可进行下单操作。
Controller中添加方法：
/**
* 要求验证的抢购接口
* @param sid
* @return
*/
@RequestMapping(value = "/createOrderWithVerifiedUrl", method = {RequestMethod.GET})
@ResponseBody
public String createOrderWithVerifiedUrl(@RequestParam(value = "sid") Integer sid,
@RequestParam(value = "userId") Integer userId,
@RequestParam(value = "verifyHash") String verifyHash) {
int stockLeft;
try {
stockLeft = orderService.createVerifiedOrder(sid, userId, verifyHash);
LOGGER.info("购买成功，剩余库存为: [{}]", stockLeft);
} catch (Exception e) {
LOGGER.error("购买失败：[{}]", e.getMessage());
return e.getMessage();
}
return String.format("购买成功，剩余库存为：%d", stockLeft);
}
OrderService中添加方法：
@Override
public int createVerifiedOrder(Integer sid, Integer userId, String verifyHash) throws Exception {
// 验证是否在抢购时间内
LOGGER.info("请自行验证是否在抢购时间内,假设此处验证成功");
// 验证hash值合法性
String hashKey = CacheKey.HASH_KEY.getKey() + "_" + sid + "_" + userId;
String verifyHashInRedis = stringRedisTemplate.opsForValue().get(hashKey);
if (!verifyHash.equals(verifyHashInRedis)) {
throw new Exception("hash值与Redis中不符合");
}
LOGGER.info("验证hash值合法性成功");
// 检查用户合法性
User user = userMapper.selectByPrimaryKey(userId.longValue());
if (user == null) {
throw new Exception("用户不存在");
}
LOGGER.info("用户信息验证成功：[{}]", user.toString());
// 检查商品合法性
Stock stock = stockService.getStockById(sid);
if (stock == null) {
throw new Exception("商品不存在");
}
LOGGER.info("商品信息验证成功：[{}]", stock.toString());
//乐观锁更新库存
saleStockOptimistic(stock);
LOGGER.info("乐观锁更新库存成功");
//创建订单
createOrderWithUserInfo(stock, userId);
LOGGER.info("创建订单成功");
return stock.getCount() - (stock.getSale()+1);
}
代码解释：
可以看到service中，我们需要验证了：
商品信息
用户信息
时间
库存
如此，我们便完成了一个拥有验证的下单接口。
试验一下接口
我们先让用户1，法外狂徒张三登场，发起请求：
http://localhost:8080/getVerifyHash?sid=1&userId=1
得到结果:
控制台输出：
别急着下单，我们看一下redis里有没有存储好key：
木偶问题，接下来，张三可以去请求下单了！
http://localhost:8080/createOrderWithVerifiedUrl?sid=1&userId=1&verifyHash=d4ff4c458da98f69b880dd79c8a30bcf
得到输出结果：
法外狂徒张三抢购成功了！
单用户限制频率
假设我们做好了接口隐藏，但是像我上面说的，总有无聊的人会写一个复杂的脚本，先请求hash值，再立刻请求购买，如果你的app下单按钮做的很差，大家都要开抢后0.5秒才能请求成功，那可能会让脚本依然能够在大家前面抢购成功。
我们需要在做一个额外的措施，来限制单个用户的抢购频率。
其实很简单的就能想到用redis给每个用户做访问统计，甚至是带上商品id，对单个商品做访问统计，这都是可行的。
我们先实现一个对用户的访问频率限制，我们在用户申请下单时，检查用户的访问次数，超过访问次数，则不让他下单！
使用Redis/Memcached
我们使用外部缓存来解决问题，这样即便是分布式的秒杀系统，请求被随意分流的情况下，也能做到精准的控制每个用户的访问次数。
Controller中添加方法：
/**
* 要求验证的抢购接口 + 单用户限制访问频率
* @param sid
* @return
*/
@RequestMapping(value = "/createOrderWithVerifiedUrlAndLimit", method = {RequestMethod.GET})
@ResponseBody
public String createOrderWithVerifiedUrlAndLimit(@RequestParam(value = "sid") Integer sid,
@RequestParam(value = "userId") Integer userId,
@RequestParam(value = "verifyHash") String verifyHash) {
int stockLeft;
try {
int count = userService.addUserCount(userId);
LOGGER.info("用户截至该次的访问次数为: [{}]", count);
boolean isBanned = userService.getUserIsBanned(userId);
if (isBanned) {
return "购买失败，超过频率限制";
}
stockLeft = orderService.createVerifiedOrder(sid, userId, verifyHash);
LOGGER.info("购买成功，剩余库存为: [{}]", stockLeft);
} catch (Exception e) {
LOGGER.error("购买失败：[{}]", e.getMessage());
return e.getMessage();
}
return String.format("购买成功，剩余库存为：%d", stockLeft);
}
UserService中增加两个方法：
addUserCount：每当访问订单接口，则增加一次访问次数，写入Redis
getUserIsBanned：从Redis读出该用户的访问次数，超过10次则不让购买了！不能让张三做法外狂徒。
@Override
public int addUserCount(Integer userId) throws Exception {
String limitKey = CacheKey.LIMIT_KEY.getKey() + "_" + userId;
String limitNum = stringRedisTemplate.opsForValue().get(limitKey);
int limit = -1;
if (limitNum == null) {
stringRedisTemplate.opsForValue().set(limitKey, "0", 3600, TimeUnit.SECONDS);
} else {
limit = Integer.parseInt(limitNum) + 1;
stringRedisTemplate.opsForValue().set(limitKey, String.valueOf(limit), 3600, TimeUnit.SECONDS);
}
return limit;
}
@Override
public boolean getUserIsBanned(Integer userId) {
String limitKey = CacheKey.LIMIT_KEY.getKey() + "_" + userId;
String limitNum = stringRedisTemplate.opsForValue().get(limitKey);
if (limitNum == null) {
LOGGER.error("该用户没有访问申请验证值记录，疑似异常");
return true;
}
return Integer.parseInt(limitNum) > ALLOW_COUNT;
}
试一试接口
使用前文用的JMeter做并发访问接口30次，可以看到下单了10次后，不让再购买了：
大功告成了。
能否不用Redis/Memcached实现用户访问频率统计
且慢，如果你说你不愿意用redis，有什么办法能够实现访问频率统计吗，有呀，如果你放弃分布式的部署服务，那么你可以在内存中存储访问次数，比如：
Google Guava的内存缓存
状态模式
不知道大家的设计模式复习的怎么样了，如果没有复习到状态模式，可以先去看看状态模式的定义。状态模式很适合实现这种访问次数限制场景。
这里我就不实现了，毕竟咱们还是分布式秒杀服务为主，不过引用一个博客的例子，大家感受下状态模式的实际应用：
https://www.cnblogs.com/java-my-life/archive/2012/06/08/2538146.html
考虑一个在线投票系统的应用，要实现控制同一个用户只能投一票，如果一个用户反复投票，而且投票次数超过5次，则判定为恶意刷票，要取消该用户投票的资格，当然同时也要取消他所投的票；如果一个用户的投票次数超过8次，将进入黑名单，禁止再登录和使用系统。
public class VoteManager {
//持有状体处理对象
private VoteState state = null;
//记录用户投票的结果，Map<String,String>对应Map<用户名称，投票的选项>
private Map<String,String> mapVote = new HashMap<String,String>();
//记录用户投票次数，Map<String,Integer>对应Map<用户名称，投票的次数>
private Map<String,Integer> mapVoteCount = new HashMap<String,Integer>();
/**
* 获取用户投票结果的Map
*/
public Map<String, String> getMapVote() {
return mapVote;
}
/**
* 投票
* @param user 投票人
* @param voteItem 投票的选项
*/
public void vote(String user,String voteItem){
//1.为该用户增加投票次数
//从记录中取出该用户已有的投票次数
Integer oldVoteCount = mapVoteCount.get(user);
if(oldVoteCount == null){
oldVoteCount = 0;
}
oldVoteCount += 1;
mapVoteCount.put(user, oldVoteCount);
//2.判断该用户的投票类型，就相当于判断对应的状态
//到底是正常投票、重复投票、恶意投票还是上黑名单的状态
if(oldVoteCount == 1){
state = new NormalVoteState();
}
else if(oldVoteCount > 1 && oldVoteCount < 5){
state = new RepeatVoteState();
}
else if(oldVoteCount >= 5 && oldVoteCount <8){
state = new SpiteVoteState();
}
else if(oldVoteCount > 8){
state = new BlackVoteState();
}
//然后转调状态对象来进行相应的操作
state.vote(user, voteItem, this);
}
}
public class Client {
public static void main(String[] args) {
VoteManager vm = new VoteManager();
for(int i=0;i<9;i++){
vm.vote("u1","A");
}
}
}
结果：
下面的文章都有对应的原创精美PDF，在持续更新中，可以来找我催更~
原创电子书
原创思维导图
 |
以上是关于SpringBoot限制接口访问频率的主要内容，如果未能解决你的问题，请参考以下文章