从‘计数器’到‘令牌桶’：我用这4种限流算法，帮公司API扛住了618大促
从计数器到令牌桶：4种限流算法在电商大促中的实战抉择
618大促前夜，技术团队会议室的白板上写满了各种数字——预计峰值QPS 50万、核心接口响应时间必须控制在200ms内、库存服务容错率0.01%。作为负责API网关的架构师，我盯着监控大屏上那些已经开始微微上扬的曲线，意识到限流策略的选型将直接决定这次大促的成败。这不是教科书式的算法比较，而是要在用户登录风暴、商品详情页洪流、订单创建浪涌等真实场景中，为每个接口匹配最合适的"流量守门人"。
1. 限流算法的战场地图
在分布式系统的防御体系中，限流从来不是孤立存在的技术。当我们在Nginx层配置了基础限流后，发现这就像用同一把锁锁所有门——商品搜索需要容忍突发流量，而支付接口必须绝对平稳。真正有效的限流策略，需要像老练的指挥官那样，根据地形（系统架构）和敌情（流量特征）部署不同的兵种（算法）。
1.1 算法四象限评估法
通过三个核心维度对算法进行立体评估：
| 评估维度 | 固定窗口 | 滑动窗口 | 漏桶 | 令牌桶 |
|---|---|---|---|---|
| 突发容忍度 | 零容忍 | 部分容忍 | 零容忍 | 完全支持 |
| 平滑性 | 阶梯式波动 | 相对平滑 | 绝对线性 | 可控波动 |
| 实现成本 | 1行Redis命令 | 需维护时间序列 | 队列管理 | 分布式锁 |
在电商系统中，这些特性会带来截然不同的表现。比如秒杀场景的"脉冲式"流量，固定窗口可能在两个窗口切换间隙放行双倍流量，而令牌桶则能利用积攒的令牌消化第一波冲击。
1.2 性能损耗的隐藏成本
算法选择不能只看功能表现，还要考虑其对系统本身的压力：
// 固定窗口的Redis原子计数器实现 Jedis jedis = new Jedis("redis-host"); Long count = jedis.incr("api:login:" + (System.currentTimeMillis() / 1000)); if (count > 1000) throw new RateLimitExceededException();对比之下，滑动窗口需要维护时间序列数据：
# 滑动窗口的Redis Lua脚本示例 local now = tonumber(ARGV[1]) local window = 1000 # 1秒窗口 local limit = 500 # 最大请求数 redis.call('ZREMRANGEBYSCORE', KEYS[1], 0, now - window) local current = redis.call('ZCARD', KEYS[1]) if current >= limit then return 0 else redis.call('ZADD', KEYS[1], now, now) return 1 end实际压测发现：在10万QPS下，固定窗口的Redis CPU使用率比滑动窗口低40%，这对资源紧张的集群至关重要
2. 用户登录接口的限流攻防战
大促开始第1分钟，登录接口的流量曲线就像过山车般陡升。这个典型场景存在几个特殊挑战：客户端存在自动重试机制、恶意爬虫会模拟登录行为、正常用户可能频繁刷新验证码。
2.1 混合策略的实战配置
我们最终采用了分层限流架构：
第一层：Nginx固定窗口
limit_req_zone $binary_remote_addr zone=auth:10m rate=50r/s; server { location /api/login { limit_req zone=auth burst=20 nodelay; } }- 突发容量20应对页面刷新
- 硬拒绝(nodelay)防止重试风暴
第二层：应用层滑动窗口
// 基于Guava的RateLimiter改造 RateLimiter limiter = RateLimiter.create(1000.0); // QPS=1000 if (!limiter.tryAcquire()) { metrics.log("login.sliding_window.reject"); throw new BusinessException("操作过于频繁"); }- 精确控制1秒内不超过1000次
- 配合Hystrix熔断降级
第三层：账号维度令牌桶
# RedisCell模块实现 CL.THROTTLE user:12345 15 30 60 # 15容量，30秒内60次请求- 针对单账号防爆破
- 动态调整容量应对活动变化
2.2 监控埋点的艺术
有效的限流必须配合精细化的监控：
# Prometheus指标示例 login_rate_limit{ type="fixed_window", status="rejected" } 1423 login_rate_limit{ type="sliding_window", status="rejected" } 892通过对比不同层的拒绝量，我们发现固定窗口在整点时刻会出现规律性误杀，这正是窗口切换导致的临界问题。最终调整时间窗口为滑动式，误杀率下降63%。
3. 商品详情页的流量整形
商品API的流量特征截然不同：需要允许突发（用户刷新页面），但要防止雪崩（缓存击穿）。这恰好是令牌桶的完美战场。
3.1 Redisson分布式实现
// 配置分布式令牌桶 RRateLimiter rateLimiter = redissonClient.getRateLimiter("product_api"); // 每秒10个令牌，桶容量50 rateLimiter.trySetRate(RateType.OVERALL, 10, 50, RateIntervalUnit.SECONDS); // 在Spring MVC拦截器中应用 if (!rateLimiter.tryAcquire()) { // 返回缓存的老版本数据 return cachedProductService.getCachedVersion(productId); }关键参数调优过程：
- 初始设置10/s的速率导致大促时缓存命中率骤降
- 通过压测发现SSD能承受的数据库QPS实际为200/s
- 最终设定基准速率80/s，突发容量500
- 配合本地缓存形成多级防御
3.2 动态调整策略
开发了基于K8s HPA的自动扩缩容机制：
# 监控脚本片段 current_qps=$(curl -s prometheus:9090/api/v1/query?query=product_api_requests) if [ $current_qps -gt 50000 ]; then kubectl scale --replicas=20 deployment/product-service redis-cli -h limiter-redis SET product_api_rate 120 fi当整体流量超过阈值时，自动提升：
- 服务实例数从10→20
- 令牌生成速率从80→120/s
- 桶容量从500→800
这套机制在预售期成功应对了三次流量洪峰，平均扩容响应时间仅12秒。
4. 下单接口的精密控制
支付环节的限流需要像手术刀般精确：既要防止超卖，又不能误伤正常交易。我们创新性地将漏桶算法与分布式事务结合。
4.1 事务型漏桶设计
// 基于数据库的漏桶实现 @Transactional public Order createOrder(OrderRequest request) { // 1. 检查漏桶水位 RateLimitRecord record = rateLimitDao.selectForUpdate(request.getUserId()); long now = System.currentTimeMillis(); long leaked = (now - record.getLastUpdate()) * RATE / 1000; int newWater = Math.max(0, record.getWater() - leaked); // 2. 验证并更新 if (newWater >= BUCKET_SIZE) { throw new OrderRateLimitException(); } rateLimitDao.updateWater(request.getUserId(), newWater + 1, now); // 3. 继续订单创建流程 return orderService.process(request); }关键设计点：
- 与订单事务绑定，确保限流计数准确性
- SELECT FOR UPDATE防止并发超限
- 速率(RATE)根据库存动态计算
4.2 分级降级策略
当系统压力达到不同阈值时触发相应措施：
| 压力等级 | CPU使用率 | 响应措施 | 用户体验影响 |
|---|---|---|---|
| 正常 | <60% | 全功能开放 | 无感知 |
| 警告 | 60%-75% | 关闭订单备注功能 | 次要功能不可用 |
| 严重 | 75%-85% | 启用购物车商品数量限制 | 购买流程部分受限 |
| 紧急 | >85% | 切换至排队模式 | 明显延迟但可完成交易 |
这套机制在618零点峰值期间，成功将支付系统CPU控制在82%以下，相比去年同期的91%有显著改善。
5. 秒杀系统的极限挑战
秒杀是最残酷的流量考场，我们设计了多层复合限流策略：
前端层：
- 随机排队进度条
- 按钮防重复点击
// 客户端限流脚本 let lastClick = 0; function handleSeckill() { const now = Date.now(); if (now - lastClick < 3000) { showToast("操作太频繁啦~"); return; } lastClick = now; // 提交请求... }接入层：
# 基于Lua的随机丢弃 location /seckill { access_by_lua ' if math.random() > 0.3 then ngx.exit(503) end '; }服务层：
// 令牌桶+漏桶混合 func SeckillHandler() { if !tokenBucket.Allow() { return Error("活动太火爆") } if !leakyBucket.Allow() { return Error("请稍后再试") } // 核心业务逻辑 }
最终效果：
- 100万并发请求被层层过滤
- 实际进入订单系统的仅800QPS
- 库存扣减成功率提升至99.99%
- 服务器负载始终低于70%
当大促结束的钟声响起，监控大屏上的曲线平稳回落。四种限流算法各司其职的场景化应用，不仅让我们扛住了流量洪峰，更积累了宝贵的实战经验：没有最好的算法，只有最合适的组合。就像老工匠会根据木材质地选择不同刨刀那样，优秀的架构师应该为每个API精心打磨专属的流量控制策略。