3. 滑动窗口算法：时间窗口与计数窗口的实现原理，为什么用滑动窗口

好，咱们进入熔断机制里最核心的算法环节——滑动窗口。

说实话，我见过不少团队在熔断上栽跟头，十有八九都是窗口算法没选对。要么统计滞后，要么误触发，要么干脆把服务搞崩了。嗯，今天咱们就把这块彻底讲透。

3.1 为什么需要窗口？

熔断的本质是「基于历史数据做决策」。那问题来了：历史数据怎么切？

你想想看，如果我把过去一整天的请求成功率都记下来，那今天下午3点的突发故障，会被上午10点的正常数据稀释掉。熔断器根本不会跳闸——这显然不行。

所以我们需要一个时间窗口，只关注最近一段时间内的指标。比如最近10秒、最近1分钟。

核心思想： 只统计「最近N秒」内的请求数据，超出窗口的数据自动丢弃。

3.2 固定窗口：简单但坑多

最朴素的做法是固定窗口。比如每10秒一个桶，统计桶内的请求数和失败数。

// 伪代码：固定窗口
class FixedWindow {
    long windowStart;      // 窗口起始时间
    int requestCount;      // 请求数
    int failureCount;      // 失败数
    long windowSize = 10_000; // 10秒

    boolean allowRequest() {
        long now = System.currentTimeMillis();
        if (now - windowStart > windowSize) {
            // 开启新窗口
            windowStart = now;
            requestCount = 0;
            failureCount = 0;
        }
        requestCount++;
        // 判断是否熔断...
    }
}

看着挺简单对吧？但我告诉你，固定窗口有个致命问题。

举个例子：窗口是10秒，熔断阈值是50%失败率。假设前9秒请求全部成功，第10秒突然来了大量失败请求。这时候窗口快结束了，失败率可能还没到阈值。但第10秒和第11秒交界处，两个窗口的「边界」附近，失败请求可能集中爆发——固定窗口完全感知不到。

我曾经在一个高并发支付系统里用过固定窗口，结果线上出现「每10秒抖一下」的诡异现象。查了半天，发现就是窗口边界处的请求被漏统计了。从那以后，我再也不敢在生产环境用固定窗口做熔断。

3.3 滑动窗口：更精确的统计方式

那滑动窗口是怎么解决的呢？说白了，就是把一个大窗口切成多个小格子，然后随着时间推移，不断「滑动」这个窗口。

我习惯用「时间片轮转」来理解它：

  • 把10秒的窗口切成10个1秒的小格子
  • 每个格子独立统计自己的请求数和失败数
  • 每过1秒，窗口向前滑动一格——丢弃最旧的格子，新增一个空格子
  • 当前窗口的总数据 = 所有格子的数据之和
// 伪代码：滑动窗口（时间片轮转）
class SlidingWindow {
    int bucketCount = 10;          // 10个格子
    long bucketSize = 1000;        // 每个格子1秒
    Bucket[] buckets = new Bucket[bucketCount];
    int currentIndex = 0;

    boolean allowRequest() {
        long now = System.currentTimeMillis();
        int index = (int)((now / bucketSize) % bucketCount);
        
        // 如果这个格子已经过期，重置它
        if (buckets[index].timestamp != now / bucketSize) {
            buckets[index].reset(now / bucketSize);
        }
        
        // 统计所有有效格子的数据
        int totalRequests = 0;
        int totalFailures = 0;
        for (Bucket b : buckets) {
            if (now - b.timestamp * bucketSize < bucketCount * bucketSize) {
                totalRequests += b.requests;
                totalFailures += b.failures;
            }
        }
        // 判断是否熔断...
    }
}

你看，滑动窗口的每个格子只负责1秒的数据。窗口滑动时，旧格子自然被淘汰。这样就不会出现「边界漏统计」的问题。

我个人习惯把格子数设为10~20个。太少的话精度不够，太多的话内存开销大。10个格子、每个1秒，对于大多数业务场景已经足够。

3.4 计数窗口 vs 时间窗口

这里有个容易混淆的概念：计数窗口和时间窗口。

类型 触发条件 典型场景 优点 缺点
时间窗口 固定时间间隔（如10秒） 熔断、限流 响应及时，不受流量波动影响 低流量时窗口可能空转
计数窗口 固定请求次数（如1000次） 批量任务、离线统计 统计粒度均匀 高流量时窗口切换频繁

说白了：时间窗口关注「时间」，不管你这段时间来了1个请求还是1万个请求，到点就翻篇。计数窗口关注「次数」，凑够N个请求就换下一批。

熔断场景下，我强烈推荐时间窗口。为什么？因为熔断要快速响应故障。如果采用计数窗口，假设阈值是1000次请求，但系统突然没流量了——那熔断器可能永远不触发。而时间窗口到点就检查，不会漏掉任何异常时段。

3.5 为什么非要用滑动窗口？

好，咱们回到最初的问题：为什么是滑动窗口？

我总结三个核心原因：

  1. 消除边界效应：固定窗口在边界处会「断崖式」丢失数据，滑动窗口通过细粒度格子平滑过渡。
  2. 实时性更好：每过一个小格子就更新一次统计，而不是等到整个窗口结束才刷新。
  3. 内存可控：只需要维护固定数量的格子（比如10个），不会随着时间增长而膨胀。

一句话总结： 滑动窗口用「空间换精度」，用少量内存换来了更平滑、更实时的统计能力。在熔断这种对实时性要求高的场景下，它是目前最成熟的方案。

3.6 滑动窗口的SVG结构图

下面这张图展示了滑动窗口的核心逻辑。我画的是10个格子的版本，每个格子代表1秒的数据。

滑动窗口结构图（10个格子，每个1秒） t-9s t-8s t-7s t-6s t-5s t-4s t-3s t-2s t-1s 当前 ← 当前10秒窗口范围 → 滑动方向 每过1秒，最左边的格子被丢弃，新增一个空格子到最右边 颜色越深表示数据越新，红色格子表示即将被淘汰

3.7 实战中的调参建议

最后，分享几个我在实战中总结的参数调优经验：

  • 窗口大小：建议10~30秒。太短容易误触发，太长反应迟钝。
  • 格子数量：10~20个。格子越多精度越高，但内存开销也大。
  • 每个格子的大小：窗口大小 ÷ 格子数。比如10秒窗口、10个格子，每个格子就是1秒。
  • 注意：格子大小不要小于100ms，否则CPU开销会明显增加。

我建议先在灰度环境跑一周，观察窗口的统计曲线。如果发现熔断器频繁误触发，可以适当增大窗口或增加格子数。如果发现故障响应太慢，就减小窗口。

好了，滑动窗口的原理和实现就讲到这里。记住一句话：滑动窗口不是银弹，但在熔断场景下，它是最务实的选择。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →