好的，各位观众老爷，欢迎来到“码农脱口秀”现场！今天咱要聊的，是咱们后端兄弟姐妹们的老朋友，也是保护我们脆弱小服务器的贴身保镖——限流（Rate Limiting）。
想象一下，你的服务器是个小饭馆，平时顾客三三两两，你还能招呼得过来。可突然有一天，抖音上你的饭馆火了！瞬间人山人海，乌泱泱一片，全都涌进来要吃饭。厨房就那么大，厨师就那么几个，食材也有限，你怎么办？难道眼睁睁看着客人把店挤爆，厨房瘫痪，最后大家都没饭吃，差评如潮吗？😱
这时候，你就需要一个“保安”来控制人流，这就是限流！
一、限流是啥？为啥要限流？
简单来说，限流就是限制单位时间内允许通过的请求数量。就像高速公路收费站，车太多了就得限流，不然堵成停车场。
为什么要限流？
- 保护后端服务： 避免突发流量压垮服务器，导致服务崩溃。就像上面说的饭馆例子，人太多了厨房就瘫痪了。
- 防止恶意攻击： 有些黑客会发起DDoS攻击，用大量的请求冲击你的服务器，限流可以有效缓解这种攻击。
- 保证服务质量： 即使没有攻击，正常的流量高峰也可能导致服务响应变慢。限流可以保证在可承受范围内，提供稳定的服务质量。
- 节省资源： 限制不必要的请求，减少服务器的负载，从而节省资源。
二、限流的常见算法：都是套路啊！
限流算法就像保安的各种“套路”，各有千秋，适用于不同的场景。
-
固定窗口计数器（Fixed Window Counter）：
- 原理： 将时间划分为固定大小的窗口，比如1分钟。在每个窗口内，记录请求的数量。如果请求数量超过了设定的阈值，就拒绝后续请求。
- 优点： 实现简单，容易理解。
- 缺点： 存在“临界问题”。比如，如果阈值是100个请求/分钟，在第一个窗口的最后1秒来了100个请求，第二个窗口的开始1秒又来了100个请求，那么在短短2秒内，服务器处理了200个请求，超过了预期的限制。就像保安只管每小时放多少人，不管他们是不是集中在某一分钟涌进来。
- 比喻： 就像一个水桶，每分钟清空一次，你往里面倒水，如果倒多了就溢出来了。
|------------------ 1分钟 -----------------| | 请求请求请求请求请求... (达到阈值) | 拒绝请求 | -
滑动窗口计数器（Sliding Window Counter）：
- 原理： 解决了固定窗口的临界问题。它将时间窗口划分为更小的子窗口，比如将1分钟划分为60个1秒的子窗口。每个子窗口记录请求的数量，然后计算当前窗口（包含多个子窗口）的总请求数量。
- 优点： 精度更高，能更平滑地限制流量。
- 缺点： 实现相对复杂，需要维护多个子窗口的计数器。
- 比喻： 就像一个滑动的游标卡尺，实时测量当前窗口内的请求数量。
|---1秒---|---1秒---|---1秒---|...|---1秒---| (总共60个1秒子窗口) | 请求数 | 请求数 | 请求数 |...| 请求数 | -
漏桶算法（Leaky Bucket）：
- 原理： 想象一个漏桶，请求就像水一样倒入桶中。桶以恒定的速率漏水（处理请求），如果水流速度超过了漏水速度，桶就会溢出（拒绝请求）。
- 优点： 可以平滑流量，避免突发流量冲击后端服务。
- 缺点： 不能处理突发的高并发请求。
- 比喻： 就像一个水龙头，不管你开多大，水桶里的水总是以固定的速度流出去。
请求 --> 漏桶 --> 处理 | 拒绝请求(溢出) -
令牌桶算法（Token Bucket）：
- 原理： 想象一个令牌桶，系统以恒定的速率往桶里放入令牌。每个请求需要拿到一个令牌才能通过，如果桶里没有令牌，请求就会被拒绝。
- 优点： 允许一定程度的突发流量，因为桶里可以预先存放一些令牌。
- 缺点： 实现相对复杂，需要维护令牌桶的状态。
- 比喻： 就像一个自动售票机，每隔一段时间吐出一张票，你需要拿着票才能进场。
令牌桶 --> 请求 --> 处理 | 拒绝请求(没令牌)表格总结：
算法 优点 缺点 适用场景 固定窗口计数器 实现简单，容易理解 存在临界问题 简单粗暴的限流，对精度要求不高的场景 滑动窗口计数器 精度高，能更平滑地限制流量 实现相对复杂 对精度要求较高的场景 漏桶算法 可以平滑流量，避免突发流量冲击后端服务 不能处理突发的高并发请求 对流量平滑性要求高的场景 令牌桶算法 允许一定程度的突发流量，更灵活 实现相对复杂 允许一定突发流量，对响应时间有要求的场景
三、限流的实现方式：代码才是王道！
理论说了一堆，不如撸起袖子敲代码。限流的实现方式有很多种，可以从不同的层面进行：
-
客户端限流：
- 原理： 在客户端（比如浏览器、APP）进行限流。
- 优点： 可以减少不必要的请求，降低服务器的压力。
- 缺点： 容易被绕过，安全性较低。
- 适用场景： 简单的前端限流，比如防止用户频繁点击按钮。
// 简单的JS限流示例 let lastClickTime = 0; const delay = 1000; // 1秒内只能点击一次 function handleClick() { const now = Date.now(); if (now - lastClickTime < delay) { alert("请不要点击太快！"); return; } lastClickTime = now; // 执行实际操作 console.log("执行操作"); } -
服务端限流：
-
原理： 在服务端进行限流，可以更有效地保护后端服务。
-
优点： 安全性高，可以防止恶意攻击。
-
缺点： 需要消耗服务器资源。
-
适用场景： 大部分限流场景。
-
实现方式：
- 基于中间件： 比如Nginx、HAProxy等，可以配置限流规则。
- 基于代码： 在代码中实现限流逻辑，可以使用第三方库，比如Guava RateLimiter（Java）、Throttler（Python）等。
-
Nginx限流示例：
http { limit_req_zone $binary_remote_addr zone=mylimit:10m rate=1r/s; server { location /api/ { limit_req zone=mylimit burst=5 nodelay; proxy_pass http://backend_server; } } }limit_req_zone: 定义一个限流区域，$binary_remote_addr表示根据客户端IP进行限流，zone=mylimit:10m表示区域名称为mylimit，大小为10MB，rate=1r/s表示允许每秒1个请求。limit_req: 应用限流规则，zone=mylimit表示使用mylimit区域的规则，burst=5表示允许突发5个请求，nodelay表示不延迟处理突发请求。
-
Guava RateLimiter示例（Java）：
import com.google.common.util.concurrent.RateLimiter; public class RateLimiterExample { private static final RateLimiter rateLimiter = RateLimiter.create(5); // 每秒允许5个请求 public static void main(String[] args) { for (int i = 0; i < 10; i++) { double waitTime = rateLimiter.acquire(); // 获取令牌，如果令牌桶中没有令牌，则等待 System.out.println("请求" + i + "，等待时间：" + waitTime); // 处理请求 processRequest(i); } } private static void processRequest(int requestId) { System.out.println("处理请求：" + requestId); } }
-
-
分布式限流：
-
原理： 在分布式系统中，需要使用分布式锁或Redis等工具来实现全局限流。
-
优点： 可以保证在整个集群范围内进行限流。
-
缺点： 实现复杂，需要考虑分布式锁的性能和可靠性。
-
适用场景： 分布式系统中的全局限流。
-
基于Redis的分布式限流示例（Python）：
import redis import time class RedisRateLimiter: def __init__(self, redis_host, redis_port, rate, burst): self.redis = redis.Redis(host=redis_host, port=redis_port) self.rate = rate # 每秒允许的请求数 self.burst = burst # 允许的突发请求数 self.script = self.redis.register_script(""" local key = KEYS[1] local rate = tonumber(ARGV[1]) local burst = tonumber(ARGV[2]) local now = tonumber(ARGV[3]) local ttl = 1 local allowed = burst local current = redis.call("get", key) if current then allowed = math.min(burst, current + rate * (now - redis.call("pttl", key) / 1000)) end if allowed < 1 then return 0 else redis.call("setex", key, ttl, allowed - 1) return 1 end """) def is_allowed(self, key): now = time.time() return self.script(keys=[key], args=[self.rate, self.burst, now]) == 1 # 使用示例 rate_limiter = RedisRateLimiter(redis_host='localhost', redis_port=6379, rate=1, burst=5) for i in range(10): if rate_limiter.is_allowed(key='user123'): print(f"请求 {i}: 允许") # 处理请求 else: print(f"请求 {i}: 拒绝") time.sleep(0.2)- 这个例子使用了Redis的Lua脚本来实现原子性的限流逻辑。
register_script方法注册了一个Lua脚本，该脚本会根据传入的参数（rate, burst, now）来判断是否允许请求。is_allowed方法调用该脚本，并返回结果。
-
四、限流的策略：灵活应对！
限流不是一成不变的，需要根据实际情况制定灵活的策略。
- 基于用户ID限流： 针对单个用户进行限流，防止恶意用户占用过多资源。
- 基于IP地址限流： 针对单个IP地址进行限流，防止恶意攻击。
- 基于接口限流： 针对不同的接口进行限流，保护核心接口。
- 基于QPS限流： 限制每秒钟允许通过的请求数量。
- 基于并发数限流： 限制同时处理的请求数量。
五、限流的注意事项：细节决定成败！
- 选择合适的算法： 根据实际场景选择合适的限流算法。
- 设置合理的阈值： 阈值设置过低会影响用户体验，阈值设置过高则起不到限流的作用。
- 考虑系统容量： 限流阈值应该根据系统的实际容量来设置。
- 监控和报警： 实时监控限流效果，及时调整策略。
- 友好的提示： 当请求被拒绝时，应该给用户友好的提示，而不是直接返回错误。比如：“服务器繁忙，请稍后再试”。
六、总结：限流是门艺术！
限流不是简单的技术活，而是一门艺术。需要在性能、可用性、用户体验之间找到平衡点。就像一个优秀的保安，既要能有效地控制人流，又要让顾客感到舒适和满意。
希望今天的“码农脱口秀”能帮助大家更好地理解和应用限流技术。记住，保护好你的服务器，才能让你的代码跑得更欢快！ 🥳
各位观众老爷，咱们下期再见！👋