基于Redis和Lua实现分布式令牌桶限流

限流是什么

通过某种手段对某个时间段的并发访问请求进行流量限制，一旦流量达到限制阈值则可以拒绝服务，排队或等待，目的是防止系统因大流量或突发流量导致服务不可用或崩溃，是一种确保系统高可用的手段。

限流的简单了解

对外限流：

电商秒杀（因秒杀业务特性，需要限流）：到达开卖时间瞬间大流量，此时下单人数>商品库存，服务器不可能同时全部消费，需要进行限流，卖完了之后就拒绝后续下单请求。

微博热搜（因产品特性，需要限流）：突然出现了几个大瓜，那微博是不是突然流量激增，重灾区就是微博热搜，此时所有服务满载运行，必须有个限流策略保证服务的高可用。

防止恶意攻击（突发恶意攻击，需要限流）：比如某一个 API 被疯狂请求，或者某一个 IP 疯狂请求公司的 API，此时就需要进行限流，常见措施是先告警，再限流。为了不影响其他服务的正常使用，需要设计限流方案。

API有偿调用：用户认证+限流策略，顾名思义没啥好说的，一般是 SAAS 公司最常见的业务，常见于 OPEN-API 相关的小组负责的。

对内限流：

BUG预防：核心服务的高可用是十分重要的，千万不能挂。如果内部应用出现 bug，一直调用核心服务，核心服务就有被击垮的风险，限流也十分重要。

缓存雪崩：请求直接打到 DB，那就哦豁完蛋了，所以需要根据业务场景来实现限流后是排队还是丢弃。

限流解决了什么问题

保证服务高可用，牺牲一部分的流量，换取服务的可用性。对于被限流器直接作用的应用来说，除了保证自身不被流量击垮，还保护了依赖它的下游应用。

限流带来的问题

任何技术都是双刃剑，没有绝对的好用，能带来优点必然也会带来问题。

限流组件保证了高可用，牺牲了性能，增加了一层 IO 环节的开销，单机限流在本地，分布式限流还要通过网络协议。

限流组件保证了高可用，牺牲了一致性，在大流量的情况下，请求的处理会出现延迟的情况，这种场景便无法保证强一致性。特殊情况下，还无法保证最终一致性，部分请求直接被抛弃。

限流组件拥有流控权，若限流组件挂了，会引起雪崩效应，导致请求与业务的大批量失败。

引入限流组件，增加系统的复杂程度，开发难度增加，限流中间件的设计本身就是一个复杂的体系，需要综合业务与技术去思考与权衡，同时还要确保限流组件本身的高可用与性能，极大增加工作量，甚至需要一个团队去专门开发。

设计限流组件本身需要考虑的点

如果我来设计限流组件，我大致会确认如下几个点：

1.明确限流器的目的：

用在哪些模块？

应对哪些场景下的什么问题?

是单机限流还是分布式限流?

确定限流模块的使用层面？例如：单应用维度、业务域维度、网关维度

2.明确限流器的维度，例如 IP 维度，用户授权 token 维度，API 维度等

3.怎么保证限流组件的高可用？

4.怎么解决使用限流组件后带来的一致性问题？

5.怎么缩小限流器的粒度，实现平滑限流？

常见的限流实现

单机

基于Java 并发工具

（信号量 / concurrentHashMap）

基于Google Guava RateLimiter

稳定模式(SmoothBursty:令牌生成速度恒定) / 渐进模式(SmoothWarmingUp:令牌生成速度缓慢提升直到维持在一个稳定值)

分布式

（Redis + Lua / Nginx + Lua）

常见限流器种类

这四种限流器虽然网上介绍得很多，但是我写给自己看的 ^_^，自己要每次遇到都能够脱口而出，而不是“我经常看到过，但是我记不起来了”或者“我知道是什么意思，但是我就是说不出来，也说不清楚”。后续, 等API网关的限流模块代码完成后, 对着代码和实践会仔细展开说说 ~

计数器（固定窗口限流器）

滑动窗口限流器

令牌桶限流器

漏桶限流器

模拟的场景

模拟API 网关中的一个 API 接口在某个时刻突然接收到 100 个并发请求，但是该 API 配置的令牌桶限流器每1分钟生成一个，每次限流间隔为 1 小时，限流上限为 60，则通过代码模拟出最终效果，并输出日志。

实现的效果

构建请求

通过参数可知，限流器的类别LimiterType选择的是令牌桶，限流的时间单位timeUnit是每小时，每个限流时间内的令牌桶内令牌的最大数量value是 60.