引言- 在web开辟中功用是基石，除了功用之外运维和防护就是重头戏了。由于在网站运转时代能够会由于忽然的拜候量致使营业异常、也有能够蒙受他人恶意进犯
- 所以我们的接口需要对流量停止限制。俗称的QPS也是对流量的一种描写
- 针对限流现在大多应当是令牌桶算法，由于它能保证更多的吞吐量。除了令牌桶算法还有他的前身漏桶算法和简单的计数算法
- 下面我们来看看这四种算法
固按时候窗口算法- 固按时候窗口算法也可以叫做简单计数算法。网上有很多都将计数算法零丁抽离出来。可是笔者以为计数算法是一种思惟，而固按时候窗口算法是他的一种实现
- 包括下面滑动时候窗口算法也是计数算法的一种实现。由于计数假如反面时候停止绑定的话那末落空了限流的本质了。就酿成了拒绝了
优点- 在牢固的时候内出现流量溢出可以立即做出限流。每个时候窗口不会相互影响
- 在时候单元内保障系统的稳定。保障的时候单元内系统的吞吐量上限
弱点- 正如图示一样，他的最大题目就是临界状态。在临界状态最坏情况会遭到两倍流量请求
- 除了临界的情况，还有一种是在一个单元时候窗内前期假如很快地消耗完请求阈值。那末剩下的时候将会没法请求。这样就会由于一瞬间的流量致使一段时候内系统不成用。这在互联网高可用的系统中是不能接管的。
实现- 好了，关于道理先容及优弱点我们已经领会了。下面我们脱手实现它
- 首先我们在实现这类计数时，采用redis是很是好的挑选。这里我们经过redis实现
controller@RequestMAPPing(value = "/start",method = RequestMethod.GET) public Map<String,Object> start(@RequestParam Map<String, Object> paramMap) { return testService.startQps(paramMap); }
service@Overridepublic Map<String, Object> startQps(Map<String, Object> paramMap) { //按照前端传递的qps上线 Integer times = 100; if (paramMap.containsKey("times")) { times = Integer.valueOf(paramMap.get("times").toString()); } String redisKey = "redisQps"; RedisAtomicInteger redisAtomicInteger = new RedisAtomicInteger(redisKey, redisTemplate.getConnectionFactory()); int no = redisAtomicInteger.getAndIncrement(); //设备时候固按时候窗口长度 1S if (no == 0) { redisAtomicInteger.expire(1, TimeUnit.SECONDS); } //判定能否超限 time=2 暗示qps=3 if (no > times) { throw new RuntimeException("qps refuse request"); } //返回成功奉告 Map<String, Object> map = new HashMap<>(); map.put("success", "success"); return map;}
成果测试
- 我们设备的qps=3 ， 我们可以看到五个并发进来后前三个一般拜候，前面两个就失利了。稍等一段时候我们在并发拜候，前三个又可以一般拜候。说明到了下一个时候窗口
滑动时候窗口算法- 针对固按时候窗口的弱点--临界值出现双倍流量题目。 我们的滑动时候窗口就发生了。
- 实在很好了解，就是针对固按时候窗口，将时候窗口统计从本来的牢固间隔酿成加倍细度化的单元了。
- 在上面我们固按时候窗口演示中我们设备的时候单元是1S 。 针对1S我们将1S拆成时候戳。
- 固按时候窗口是统计单元随着时候的推移不竭向落后行。而滑动时候窗口是我们以为的设想出一个时候单元依拍照对论的思惟将时候牢固，我们的笼统时候单元自己移动。笼统的时候单元比现实的时候单元更小。
- 读者可以看下下面的动图，便可以了解了。
优点- 本色上就是固按时候窗口算法的改良。所以固按时候窗口的弱点就是他的优点。
- 内部笼统一个滑动的时候窗，将时候加倍小化。存在鸿沟的题目加倍小。客户感知更弱了。
弱点- 非论是固按时候窗口算法还是滑动时候窗口算法，他们都是基于计数器算法停止优化，可是他们看待限流的战略太粗鲁了。
- 为什么说粗鲁呢，未限流他们一般放行。一旦到达限流后就会间接拒绝。这样我们会损失一部分请求。这对于一个产物来说不太友爱
实现- 滑动时候窗口是将时候加倍细化，上面我们是经过redis#setnx实现的。这里我们就没法经过他同一记录了。我们应当加上更小的时候单元存储到一个调集汇总。然后按照调集的总量计较限流。redis的zsett数据结构就和合适我们的需求。
- 为什么挑选zset呢，由于redis的zset中除了值之外还有一个权重。会按照这个权重停止排序。假如我们将我们的时候单元实时候戳作为我们的权重，那末我们获得统计的时辰只需要依照一个时候戳范围便可以了。
- 由于zset内元素是唯一的，所以我们的值采用uuid大概雪花算法一类的id天生器
controller@RequestMapping(value = "/startList",method = RequestMethod.GET) public Map<String,Object> startList(@RequestParam Map<String, Object> paramMap) { return testService.startList(paramMap); }
serviceString redisKey = "qpsZset"; Integer times = 100; if (paramMap.containsKey("times")) { times = Integer.valueOf(paramMap.get("times").toString()); } long currentTimeMillis = System.currentTimeMillis(); long interMills = inter * 1000L; Long count = redisTemplate.opsForZSet().count(redisKey, currentTimeMillis - interMills, currentTimeMillis); if (count > times) { throw new RuntimeException("qps refuse request"); } redisTemplate.opsForZSet().add(redisKey, UUID.randomUUID().toString(), currentTimeMillis); Map<String, Object> map = new HashMap<>(); map.put("success", "success"); return map;
成果测试
- 和固按时候窗口采用不异的并发。为什么上面也会出现临界状态呢。由于在代码里时候单元间隔比固按时候间隔采用还要大 。 上面演示固按时候窗口时候单元是1S出现了最坏情况。而滑动时候窗口设想上就应当间隔更短。而我设备成10S 也没有出现坏的情况
- 这里就说明滑动比牢固的优处了。假如我们调更小应当加倍不会出现临界题目，不外说到底他还是避免不了临界出现的题目
漏桶算法- 滑动时候窗口虽然可以极洪流高山躲避临界值题目，可是始终还是避免不了
- 别的时候算法还有个致命的题目，他没法面临突如其来的大量流量，由于他在到达限流后间接就拒绝了其他额外流量
- 针对这个题目我们继续优化我们的限流算法。 漏桶算法应运而生
优点- 面临限流加倍的柔性，不再粗鲁的拒绝。
- 增加了接口的接收性
- 保证下贱办事接收的稳定性。均匀下发
弱点- 我感觉没有弱点。非要鸡蛋里挑骨头那我只能说漏桶容量是个短板
实现controller@RequestMapping(value = "/startLoutong",method = RequestMethod.GET)public Map<String,Object> startLoutong(@RequestParam Map<String, Object> paramMap) { return testService.startLoutong(paramMap);}
service- 在service中我们经过redis的list的功用模拟出桶的结果。这里代码是尝试室性质的。在实在利用中我们还需要斟酌并发的题目
@Overridepublic Map<String, Object> startLoutong(Map<String, Object> paramMap) { String redisKey = "qpsList"; Integer times = 100; if (paramMap.containsKey("times")) { times = Integer.valueOf(paramMap.get("times").toString()); } Long size = redisTemplate.opsForList().size(redisKey); if (size >= times) { throw new RuntimeException("qps refuse request"); } Long aLong = redisTemplate.opsForList().rightPush(redisKey, paramMap); if (aLong > times) { //为了避免并发场景。这里增加完成以后也要考证。 即使这样本段代码在高并发也有题目。此处演示感化 redisTemplate.opsForList().trim(redisKey, 0, times-1); throw new RuntimeException("qps refuse request"); } Map<String, Object> map = new HashMap<>(); map.put("success", "success"); return map;}
下流消耗@Componentpublic class SchedulerTask { @Autowired RedisTemplate redisTemplate; private String redisKey="qpsList"; @Scheduled(cron="*/1 * * * * ?") private void process(){ //一次性消耗两个 System.out.println("正在消耗。。。。。。"); redisTemplate.opsForList().trim(redisKey, 2, -1); }}
测试- 我们还是经过50并发循环10次拜候。我们可以发现只要在一路头能到达比力高的吞吐量。在随后桶的容量满了以后。而下流水滴速度比上游请求速度慢的情况下。只能以下流恒定的速度接收拜候。
- 他的题目也表露得很明显。针对时候窗口的不敷漏桶停止的不敷，可是还是不敷。没法完全避免请求溢出的题目。
- 请求溢出自己就是一种灾难性的题目。一切的算法今朝都没有处理这个题目。只是在减缓他带来的题目
令牌桶算法- 令牌桶和漏桶法是一样的。只不外将桶的感化偏向改变了一下。
- 漏桶的出水速度是恒定的，假如流量忽然增加的话我们就只能拒绝入池
- 可是令牌桶是将令牌放入桶中，我们晓得一般情况命令牌就是一串字符当桶满了就拒绝令牌的入池，可是面临高流量的时辰一般加上我们的超不时候就留下充足长的时候生产及消耗令牌了。这样就尽能够地不会形成请求的拒绝
- 最初，非论是对于令牌桶拿不到令牌被拒绝，还是漏桶的水满了溢出，都是为了保证大部分流量的一般利用，而牺牲掉了少部分流量
public Map<String, Object> startLingpaitong(Map<String, Object> paramMap) { String redisKey = "lingpaitong"; String token = redisTemplate.opsForList().leftPop(redisKey).toString(); //一般情况需要考证能否正当，避免篡改 if (StringUtils.isEmpty(token)) { throw new RuntimeException("令牌桶拒绝"); } Map<String, Object> map = new HashMap<>(); map.put("success", "success"); return map; }
@Scheduled(cron="*/1 * * * * ?") private void process(){ //一次性生产两个 System.out.println("正在消耗。。。。。。"); for (int i = 0; i < 2; i++) { redisTemplate.opsForList().rightPush(redisKey, i); } }
原文链接：https://juejin.cn/post/6967704472109711367
|
