朋友公司做秒杀，限流用的是固定窗口计数器——每分钟最多 1000 个请求。每次秒杀开始的瞬间，前 0.5 秒冲进来 800 个请求，计数器直接打满，后面 59.5 秒的正常用户一个都进不来。更要命的是，这个计数器在第 60 秒重置，第 61 秒又是一波 800 个请求冲进来。限流器没有挡住流量洪峰，反而把正常用户拦在了门外。 固定窗口的问题是它不管流量分布。1000 个请求挤在前 5 秒和均匀分布在 60 秒里，对它来说是一样的——反正超了就拒。但业务上，前 5 秒的 800 个秒杀请求是正常的，后面的零散查询也是正常的。你需要的不是"别超过 1000"，而是"别把服务器打爆"。 这就是令牌桶擅长的事。 令牌桶和固定窗口的差别在哪 固定窗口的逻辑很粗暴：一个计数器，到时间清零。令牌桶的思路完全反过来——以固定的速度往桶里放令牌，请求来了要先拿到令牌才能通过。 令牌桶模型： 令牌生成器 —→ 每秒放 100 个令牌 —→ [桶容量: 200] │ 请求到达 ────────────────────────────────┤ │ 有令牌？—→ 拿走一个，放行 │ 没令牌？—→ 拒绝 │....

在高并发的互联网应用中，流量控制是一个绕不开的话题。想象一下，当某个热点事件引发流量洪峰时，如果没有有效的限流措施，你的服务器很可能瞬间被击垮，导致服务不可用。今天，我要跟大家分享两种经典的限流算法——令牌桶和滑动窗口，以及如何在SpringBoot中实现它们。 为什么需要限流？ 在讲具体实现之前，我们先来看看为什么需要限流： 保护系统稳定性：防止突发流量压垮系统 保障服务质量：确保核心功能在高负载下仍能正常服务 资源合理分配：防止恶意用户占用过多资源 成本控制：避免不必要的资源消耗 令牌桶算法详解 令牌桶算法就像一个固定容量的桶，系统以恒定速率向桶中添加令牌。每当有请求到来时，需要从桶中取出一个令牌才能继续处理。如果桶中没有令牌，则请求被拒绝。 令牌桶的特点： 平滑突发流量：允许一定程度的突发请求 恒定速率：令牌按固定速率产生 容量限制：桶有最大容量，多余的令牌会被丢弃 令牌桶的实现： @Service public class TokenBucketRateLimiter { // 令牌桶缓存 private final Cache<String, TokenBuck....