瞧瞧别人家的限流，那叫一个优雅！

前言

去年夏天某个凌晨，我接到某金融平台报警：支付接口错误率飙升至35%。
赶到机房时，发现数据库连接池耗尽，大量请求堆积成山——这就是典型的未做限流防护的灾难现场。
就像高速公路不设收费站，高峰期必然堵成停车场。
限流的本质不是拒绝服务，而是用可控的牺牲保护核心链路。
某电商大促时，他们用令牌桶算法将秒杀接口QPS限制在5万，虽然流失了20%的突发流量，但保住了99%的核心交易成功率。
1 常用限流方案

1.1 固定窗口计数器

核心原理：
以固定时间窗口（如1秒）为周期，统计周期内请求数，超过阈值则拒绝后续请求。

具体代码实现如下：

1. // 线程安全实现（AtomicLong优化版）
2. public class FixedWindowCounter {
3.     private final AtomicLong counter = new AtomicLong(0);
4.     private volatile long windowStart = System.currentTimeMillis();
5.     private final int maxRequests;
6.     private final long windowMillis;
8.     public boolean tryAcquire() {
9.         long now = System.currentTimeMillis();
10.         if (now - windowStart > windowMillis) {
11.             if (counter.compareAndSet(counter.get(), 0)) {
12.                 windowStart = now;
13.             }
14.         }
15.         return counter.incrementAndGet() <= maxRequests;
16.     }
17. }

复制代码

技术痛点：
某智能家居平台用此方案，确保即使10万台设备同时上报数据，系统仍按500条/秒的速率稳定处理。
但突发流量会导致队列积压，就像用漏斗倒奶茶——珍珠容易卡住。
适用场景：
IoT设备控制指令下发、支付渠道限额等需要严格恒定速率的场景
1.4 令牌桶算法

核心原理：
以固定速率生成令牌，请求需获取令牌才能执行。
突发流量可消耗桶内积攒的令牌。

具体实现如下：

1. // Redis Lua实现滑动窗口（精确到毫秒）
2. String lua = """
3.     local now = tonumber(ARGV
4.     local window = tonumber(ARGV
5.     local key = KEYS[1]
6.    
7.     redis.call('ZREMRANGEBYSCORE', key, '-inf', now - window)
8.     local count = redis.call('ZCARD', key)
9.    
10.     if count < tonumber(ARGV then
11.         redis.call('ZADD', key, now, now)
12.         redis.call('EXPIRE', key, window/1000)
13.         return 1
14.     end
15.     return 0
16.     """;

复制代码

实战案例：
某视频平台用此方案应对热点事件：平时限制10万QPS，突发时允许3秒内超限50%，既防雪崩又保用户体验。
动态特性

• 正常时限制QPS
  
• 突发时允许透支
  
• 持续突发会耗尽令牌
  

我的技术网站，海量八股文、项目实战这里都有：www.susan.net.cn，欢迎大家访问。
2 生产环境实战

2.1 网关层分布式限流

某电商双11方案：通过Redis+Lua实现分布式计数，配合Nginx本地缓存，在网关层拦截了83%的恶意请求。

2.2 自适应熔断机制

我们还需要自适应熔断机制。
某社交平台用此方案，在突发流量时自动将限流阈值从5万降到3万，等系统恢复后再逐步提升。

3 避坑指南与性能优化

3.1 致命误区

在数据库连接池前做限流！
某公司曾因此导致连接泄漏，最终撑爆数据库。
正确做法应遵循熔断三原则：

• 快速失败：在入口层拦截无效请求
  
• 动态降级：核心服务保留最小资源
  
• 自动恢复：熔断后渐进式放量
  

3.2 性能优化

某金融系统通过JMH测试发现，使用LongAdder替代AtomicLong，限流吞吐量提升220%。

性能优化手段：减少CAS竞争 和 分段锁基座。

总结

上面列举了工作中最常用的4种限流方案。
对于不同的业务场景，我们需要选择不同的限流方案。

限流的黄金法则如下：

记住：好的限流方案就像高铁闸机——既保证通行效率，又守住安全底线。
最后说一句(求关注，别白嫖我)

如果这篇文章对您有所帮助，或者有所启发的话，帮忙关注一下我的同名公众号：苏三说技术，您的支持是我坚持写作最大的动力。
求一键三连：点赞、转发、在看。
关注公众号：【苏三说技术】，在公众号中回复：进大厂，可以免费获取我最近整理的10万字的面试宝典，好多小伙伴靠这个宝典拿到了多家大厂的offer。
本文收录于我的技术网站：http://www.susan.net.cn

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！