从‘计数器’到‘令牌桶’：我用这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 zoneauth:10m rate50r/s; server { location /api/login { limit_req zoneauth burst20 nodelay; } }突发容量20应对页面刷新硬拒绝(nodelay)防止重试风暴第二层应用层滑动窗口// 基于Guava的RateLimiter改造 RateLimiter limiter RateLimiter.create(1000.0); // QPS1000 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{ typefixed_window, statusrejected } 1423 login_rate_limit{ typesliding_window, statusrejected } 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?queryproduct_api_requests) if [ $current_qps -gt 50000 ]; then kubectl scale --replicas20 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精心打磨专属的流量控制策略。