阅读时长约 12 分钟

本章完

本章导读

说实话，限流这玩意儿，你要是没搞过可Neng觉得它就是个“挡一下流量”的小功Neng。但其实它背后那点门道可深了去了。今天咱就来唠唠，限流算法，你了解多少？

咱先从Zui简单的开始说就是那个——固定窗口限流算法。这玩意儿，说白了就是把时间切成一段一段的，比如1秒一个窗口，然后统计这个窗口里来了多少请求，超过阈值就拒绝。简单粗暴，对吧？

这算法的实现，就是搞个计数器，时间一到就清零，再重新计数。比如你设置1秒Zui多100个请求，那这一秒内，第101个请求来了直接给你拒绝，不讲情面。

害，这算法虽然简单，但有个大问题——边界突刺。啥意思呢？就是说比如你窗口是1秒，前900毫秒啥dou没来Zui后100毫秒来了100个请求，那系统就可Neng被“突突”一下打爆。这可不行，太粗暴了。

所以后来大家就搞出了滑动窗口算法，来解决这个问题。

滑动窗口算法，就是把时间窗口再细分成好几个小格子，比如1秒分成10个100毫秒的格子。这样，每次统计的时候，就kanZui近的格子加起来有没有超限。这样就比固定窗口精确多了不会出现那种“前一秒啥dou没有，后一秒爆了”的情况。

你懂的，这算法实现起来就复杂点了得维护一堆格子的计数。不过为了精确，这点复杂度算啥？

不过这算法也不是万Neng的。比如它对时间窗口的划分要求比较高，格子太粗了还是有突刺，太细了又影响性Neng。所以大家又搞出了令牌桶算法。

令牌桶算法，咱Ke以这么理解：系统就像一个桶，里面放令牌，请求来了就去桶里拿令牌，有就通过没有就拒绝。令牌是按固定速率生成的，比如每秒生成10个，桶满了就扔掉多余的令牌。

这算法的好处是啥？允许一定的突发流量。比如桶里有50个令牌，那就Ke以瞬间处理50个请求，然后再慢慢等令牌生成。是不是比漏桶温柔多了？

对了还有个漏桶算法，咱也得提一嘴。

漏桶算法，就是请求像水一样流进桶里然后以固定速率“漏水”——也就是处理请求。桶满了就溢出来请求就被拒绝了。

这算法的特点是啥？就是强制恒定速率，不管请求多猛，它dou慢慢来平滑得hen。适合那种对下游系统要求比较稳的场景，比如定时任务、批量处理啥的。

不过它不支持突发流量，所以Ru果你的系统需要应对那种“一下子来一波”的情况，漏桶就不合适了。这时候，令牌桶就geng合适。

咱来一下这几种算法的特点：

固定窗口简单粗暴，但容易边界突刺

滑动窗口精确，但实现复杂

令牌桶允许突发，适合API限流

漏桶强制恒定速率，适合流量整形

所以选哪个算法，得kan你系统的需求。比如API限流，咱就用令牌桶；需要精确控制，就用滑动窗口；要保护下游系统，就用漏桶。对吧？

单机限流搞明白了那分布式场景下咋办？

这时候就得靠Redis + Lua脚本了。Redis保证原子性，Lua脚本保证逻辑一致性。比如用滑动窗口算法，把请求记录到ZSet里然后每次请求dou判断一下窗口内的请求数，超了就拒绝。这样，就Neng在分布式环境下实现精确限流了。

不过Redis集群环境下还有个问题，就是性Neng瓶颈。所以咱还Ke以搞个本地限流 + 全局限流的双层结构。本地限流先快速判断，不行就直接拒绝，减少Redis压力；全局限流再精确控制，保证整体流量不超限。

在Spring Boot里咱Ke以自定义个注解，比如@RateLimit，然后用AOP切面来实现。这样，哪个接口要限流，直接加个注解就完事了多方便。

还Ke以用Sentinel这种限流框架，它支持多种限流策略，还Neng跟Spring Cloud集成，用起来不要太爽。

好了今天咱就唠到这儿。限流算法这玩意儿，虽然kan着简单，但真要落地，要考虑的点可不少。比如算法选型、分布式场景、多级限流、自适应限流啥的，dou是门道。

不过只要搞明白了这些，你就Neng根据业务场景，灵活选择合适的限流策略，保护系统不被流量冲垮。这不就稳了嘛！

下回咱再聊聊熔断降级，kankan系统在崩溃边缘怎么优雅地“躺平”。

📝 下一章预告

《服务熔断降级详解》- 学习服务熔断与降级策略