几种限流算法的入门与Redisson限流实现

限流入门

为什么需要限流？

控制成本

现在的问题：使用系统需要消耗成本的，用户有可能疯狂刷量，让你破产

解决问题：

1. 限制用户调用总次数，控制成本

2. 用户在短时间内疯狂使用，导致服务器资源被占满，其他用户无法使用=>限流

思考限流阀值多大合适？比如限制单个用户在每秒只能使用一次

涉及到收费 限流一定要加上

限流的几种算法

1）固定窗口限流

单位时间内同意部分操作

一小时只同意10个用户操作

优点：简单

缺点：可能出现流量突刺

比如：第59分钟没有1个操作 第59分钟来了10个操作 第1小时01分钟又来了10个操作。相当于2分钟内执行了20个操作 服务器仍然有高峰危险

2）滑动窗口限流

单位时间内同意部分操作 但是这个单位时间是滑动的 需要指定一个滑动单位

滑动单位 1min

开始前

0s 1h 2h

一分钟后

1min 1h1min

优点：能够解决固定窗口突刺的问题，因为第59分钟时，限流窗口是59分-1小时59小时，这个时间段内只能接受10次请求，只要还在这个窗口里，更多的操作就会被拒绝

缺点：实现相对复杂，限流效果和你的滑动单位有关，滑动单位越小，限流效果越好，但往往很难选取到一个特别合适的滑动单位

3）漏桶限流

以固定的速率处理请求 当请求桶满了后，拒绝请求

每秒处理10个请求 桶的容量是10 每0.1固定处理一次请求 如果1秒内来了10个请求，都可以处理完，但如果1s内来了11个请求，最后那个请求就会溢出桶，被拒绝

优点：能够一定程度上应对流量突刺

缺点：没有办法迅速处理一批请求，只能一个个按排序来处理（固定速率的缺点）

4）令牌桶限流

管理员生成一批令牌，每秒生成10个令牌；当用户要操作前，先去拿到一个令牌，有令牌的人就有资格执行操作，能同时执行操作

拿不到令牌就等着

优点:能够并发处理同时的请求，并发性能会更高

需要: 还是存在时间单位选取的问题考虑的问题

选择：要根据业务来选择，如果你希望你的服务器是用 如果你希望你的服务器恒定地处理请求，就使用漏桶牌算法 ，如果你希望你对服务器并发处理要求高，就是用令牌桶算法

限流粒度

1. 针对某个方法限流 即最大同意同时xx个操作使用这个方法

2. 针对某个用户限流 比如单个用户单位时间内最大执行xx次操作

3. 针对某个用户x方法限流,

限流的实现

1）本地限流（单机）

每个服务器单独限流，会有风险，一般适用于单体项目

guava RateLimiter google开源的库

​

2）分布式限流（多机限流）

Redisson RateLimiter

如果你的项目有多个服务器，比如微服务，建议使用分布式限流

1. 把统计用户的使用频率数据放到一个集中的储存统计 比如Redis 这样无论用户的请求（Redisson）

2. 落到了哪台服务器，都以集中的数据储存内的数据为准

3. 在网关集中进行限流或者统计（比如sentinel Spring cloud gateway）

Redisson限流实现

Redisson内置了一个限流工具类，可以帮助你利用Redis来储存，来统计

https://juejin.cn/post/7199882882138898489

RedisLimiterManager: 什么是Manager?专门提供RedisLimiter限流基础服务（提供了通用的能力）

没办法看懂方法参数的含义，怎么办？

1. 看文档

2. idea自动下载源码

注：防止重复提交是细节的限流 涉及到幂等性啥的

重要的是思想