高并发服务限流架构实践：从本地令牌桶到 Redis+Lua 分布式流控

在微服务架构与公网 API 网关的生产环境中，系统经常面临突发流量峰值、网络爬虫恶意扫描以及下游依赖服务容量受限等问题。缺乏有效的流量控制极易导致 CPU 满载、线程池耗尽甚至整个集群雪崩。限流（Rate Limiting）作为服务韧性架构的“三板斧”（限流、降级、熔断）之首，是保障系统高可用的核心技术手段。

本文梳理常见限流算法的边界特性，重点解析基于 Redis + Lua 脚本实现的分布式限流方案，并探讨生产环境下热 Key 与集群容灾的应对策略。

一、 常见限流算法演进与选型

针对不同颗粒度的流量控制诉求，主流限流算法在实现复杂度与平滑度上各有侧重：

工程选型结论：网关层与业务层通常优先选择令牌桶算法或滑动窗口算法，在限制整体吞吐的同时，允许一定程度的突发流量正常穿透。

二、 基于 Redis + Lua 的分布式精准限流

在单机环境下，使用 Guava RateLimiter 即可满足需求。但在多节点部署的集群架构中，各实例流量分布不均，必须依赖中央存储维护全局配额。为保证计数/扣减的原子性并规避网络往返时延（RTT），Redis + Lua 脚本是当前业界标准解法。

1. 滑动时间窗口限流实现

滑动窗口利用 Redis 的 ZSET 数据结构：以时间戳作为 Score，每次请求进来先剔除窗口外的过期元素，再计算窗口内的保留记录数。

-- KEYS[1]: 限流 Key（如 rate:limit:user_id:api_path）
-- ARGV[1]: 当前时间戳（毫秒）
-- ARGV[2]: 窗口时间大小（毫秒，如 1000）
-- ARGV[3]: 窗口内允许的最大请求数（如 100）

local limit_key = KEYS[1]
local current_time = tonumber(ARGV[1])
local window_size = tonumber(ARGV[2])
local max_count = tonumber(ARGV[3])

local clear_before = current_time - window_size

-- 1. 移除窗口外的历史请求记录
redis.call('ZREMRANGEBYSCORE', limit_key, '-inf', clear_before)

-- 2. 获取当前窗口内的请求计数
local current_requests = redis.call('ZCARD', limit_key)

-- 3. 判断是否超出配额
if current_requests < max_count then
    -- 记录本次请求的时间戳（使用唯一 member 避免覆盖）
    redis.call('ZADD', limit_key, current_time, current_time .. ':' .. math.random(1000, 9999))
    -- 设置 Key 的自动过期时间，防止冷数据常驻内存
    redis.call('PEXPIRE', limit_key, window_size)
    return 1 -- 放行
else
    return 0 -- 限流拦截
end

2. Python 驱动调用封装

import time
import redis

client = redis.StrictRedis(host="127.0.0.1", port=6379, db=0, decode_responses=True)

# 预加载 Lua 脚本生成 SHA1 缓存，降低网络传输开销
SLIDING_WINDOW_LUA = """..."""  # 上文 Lua 脚本内容
sliding_window_sha = client.script_load(SLIDING_WINDOW_LUA)

def is_action_allowed(user_id: str, action_key: str, period_ms: int = 1000, max_count: int = 20) -> bool:
    """
    基于滑动时间窗口判断是否放行请求
    """
    key = f"rate:limit:{user_id}:{action_key}"
    current_ms = int(time.time() * 1000)
    
    result = client.evalsha(
        sliding_window_sha,
        1,
        key,
        current_ms,
        period_ms,
        max_count
    )
    return result == 1

三、 生产环境常见坑点与高阶治理

1. Redis 单点与热 Key 击穿风险

• 问题隐患：当针对全局公共接口（如登录、商品详情）或头部大商户进行限流时，海量并发请求汇聚到单一 Redis 节点上的同一 Key，瞬间将该分片 CPU 打满。
• 规避策略：
  • 本地 + 分布式二级限流：在网关本地内存（如 Guava/Caffeine）做前置粗粒度限流，过滤掉 80% 的暴增无效请求；余下的核心配额再通过 Redis 集中核验。
  • 分片 Key（Key Splitting）：将单一限流 Key 拆分为多个子 Key（如 rate_limit:api_X_{0..N}），客户端随机或轮询路由到子 Key 上分配子限流额度。

2. 避免高并发下的 ZSET 内存爆炸

• 问题隐患：若 QPS 极高（如万级），使用 ZSET 滑动窗口会在短时间内创建数十万个元素，造成 Redis 内存暴涨以及 ZREMRANGEBYSCORE 操作耗时上升。
• 规避策略：极高并发场景下，应放弃高精度的 ZSET 滑动窗口，改为采用基于时间差换算的令牌桶 Lua 实现，仅存储 剩余令牌数 与 上次刷新时间 两个简单数值字段，计算复杂度固定为 $O(1)$。

3. 限流降级体验与容灾逃生通道

• 限流触发语义明确：被拦截的请求应遵循 HTTP 规范，返回标准状态码 429 Too Many Requests，并在响应头中附带 Retry-After: 3，告知客户端退避时间，避免前端无脑快速重试。
• Redis 宕机降级策略：限流系统必须具备“容错降级”能力。在代码中捕获 Redis 连接超时或服务不可用异常（RedisConnectionError），根据业务属性配置策略：
  • 弱限制业务（Fail-Open）：直接放行请求并记录告警日志，确保限流组件本身的故障不阻断核心主干交易。
  • 强保护业务（Fail-Close）：回退至网关本地单机静态阈值保护，防止后端服务被瞬间冲垮。