限流

四种主流算法

限流算法的选择很大程度上决定了系统在突发流量下的表现：

• 固定窗口计数器：最简单，每 1 秒内允许 100 个请求。缺点是窗口边界会被打穿——第 0.9 秒来了 100 个，第 1.1 秒又来 100 个，2 秒内实际放行了 200 个。
• 滑动窗口：记录每个请求的精确时间戳，取过去 1 秒的真实请求数，解决了边界问题，内存消耗更大。
• 漏桶（Leaky Bucket）：请求进入队列（桶），以固定速率流出处理，超出桶容量的请求被丢弃，输出极其平滑，适合对下游匀速输出的场景。
• 令牌桶（Token Bucket）：以固定速率往桶里放令牌，请求消耗令牌，桶满时令牌丢弃。允许突发——如果积累了一桶令牌，短时间内可以高速消耗。AWS API Gateway 和 Nginx 默认使用令牌桶。

分布式场景的挑战

单机限流实现简单，分布式系统的限流要复杂得多。假设限制某个用户每秒 100 次 API 调用，但服务有 10 个实例，每个实例只能感知自己的流量，单机计数无法全局生效。

常见解决方案是用 Redis 做集中计数：所有实例把计数器写到同一个 Redis key，原子自增并设过期时间。Redis 官方提供了基于此思路的 INCR + EXPIRE 脚本方案，以及更精细的 Redis Cell 模块（实现了 GCRA 通用信元速率算法）。Stripe、GitHub、Cloudflare 公开分享过各自的分布式限流实现细节。