可以了，基于Redis和Lua实现分布式令牌桶限流

限流是一个很大的话题，准备把其中的所有限流器都实现一遍，以此也算全都写过了，到时候再用也不至于会心虚，毕竟真实写完成过。本文主要讲述了如何基于 Redis 与 Lua实现分布式令牌桶的限流方案。

读前提问

我觉得学习任何东西前都应该有自己的反问，这种反问基于标题给你的大概印象。带着问题来看文章，最后应该比盲目的看有收获，先提出几个基础的问题。

限流是什么

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

限流的简单了解

限流常见场景

 

对外限流：

• 电商秒杀（因秒杀业务特性，需要限流）：到达开卖时间瞬间大流量，此时下单人数>商品库存，服务器不可能同时全部消费，需要进行限流，卖完了之后就拒绝后续下单请求。
• 微博热搜（因产品特性，需要限流）：突然出现了几个大瓜，那微博是不是突然流量激增，重灾区就是微博热搜，此时所有服务满载运行，必须有个限流策略保证服务的高可用。
• 防止恶意攻击（突发恶意攻击，需要限流）：比如某一个 API 被疯狂请求，或者某一个 IP 疯狂请求公司的 API，此时就需要进行限流，常见措施是先告警，再限流。为了不影响其他服务的正常使用，需要设计限流方案。
• API有偿调用：用户认证+限流策略，顾名思义没啥好说的，一般是 SAAS 公司最常见的业务，常见于 OPEN-API 相关的小组负责的。

对内限流：

• BUG预防：核心服务的高可用是十分重要的，千万不能挂。如果内部应用出现 bug，一直调用核心服务，核心服务就有被击垮的风险，限流也十分重要。
• 缓存雪崩：请求直接打到 DB，那就哦豁完蛋了，所以需要根据业务场景来实现限流后是排队还是丢弃。

综上所述，需要进行限流的场景可以分为三种：

1. 公共的 API ，限流策略用于open-api 网关与相关服务的可用性，同时可以防止恶意攻击。
2. 内部的核心应用，应对 bug 或其他突发情况，目的就是保证突发情况下核心应用的高可用。
3. 产品具备突发大流量请求的特性，妥妥的都给加上限流策略，保证整个系统的高可用。

限流解决了什么问题

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

限流带来的问题

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

• 限流组件保证了高可用，牺牲了性能，增加了一层 IO 环节的开销，单机限流在本地，分布式限流还要通过网络协议。
• 限流组件保证了高可用，牺牲了一致性，在大流量的情况下，请求的处理会出现延迟的情况，这种场景便无法保证强一致性。特殊情况下，还无法保证最终一致性，部分请求直接被抛弃。
• 限流组件拥有流控权，若限流组件挂了，会引起雪崩效应，导致请求与业务的大批量失败。
• 引入限流组件，增加系统的复杂程度，开发难度增加，限流中间件的设计本身就是一个复杂的体系，需要综合业务与技术去思考与权衡，同时还要确保限流组件本身的高可用与性能，极大增加工作量，甚至需要一个团队去专门开发。

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

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

1.明确限流器的目的：

• 用在哪些模块？
• 应对哪些场景下的什么问题?
• 是单机限流还是分布式限流?
• 确定限流模块的使用层面？例如：单应用维度、业务域维度、网关维度

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

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

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

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

常见的限流实现

单机

• 基于Java 并发工具

（信号量 / concurrentHashMap）

• 基于Google Guava RateLimiter

稳定模式(SmoothBursty:令牌生成速度恒定) / 渐