📚 课程目录第4章滑动窗口技术

4. 滑动窗口技术：时间窗口与计数窗口的实现原理、在熔断器中的应用

滑动窗口是熔断器实现故障统计与状态转换的核心数据结构。熔断器需要在一个连续的时间段内统计请求的成功/失败比率，而不是依赖全局计数器或固定时间点快照。滑动窗口技术通过“窗口滑动”的方式，让统计始终覆盖最近一段时间或最近一批请求，从而准确反映系统的实时健康状态。

4.1 滑动窗口的核心概念

滑动窗口由两个基本维度定义：窗口长度（Window Size）和滑动粒度（Sliding Granularity）。根据统计维度的不同，分为时间窗口和计数窗口两种实现方式。

维度	时间窗口（Time Window）	计数窗口（Count Window）
窗口定义	固定时长，如 10 秒、60 秒	固定请求数，如 100 次、1000 次
滑动触发	时间流逝，每隔固定间隔滑动	请求到达，每满固定次数滑动
统计对象	最近 N 秒内的请求	最近 N 次请求
优点	实时反映时间维度负载变化	避免时间维度下的稀疏请求误判
缺点	低流量时窗口内样本不足	高流量时窗口滑动过快，统计抖动大
典型应用	Hystrix、Resilience4j 默认实现	部分自定义熔断器、限流器

4.2 时间窗口实现原理

时间窗口将固定时长（如 10 秒）切分为多个桶（Bucket），每个桶记录一个子时间段的请求计数。窗口整体向前滑动时，最旧的桶被丢弃，最新的桶被加入。桶的数量决定了统计精度：桶越多，滑动越平滑，但内存开销越大。

关键参数：时间窗口长度（windowLengthMs）和桶数（numBuckets）。每个桶的时长 = windowLengthMs / numBuckets。例如 10 秒窗口、10 个桶，每个桶 1 秒。

4.2.1 桶的数据结构

// 桶的简化定义
class Bucket {
    long windowStart;      // 桶的开始时间戳（毫秒）
    AtomicLong successCount;  // 成功请求数
    AtomicLong failureCount;  // 失败请求数
    AtomicLong timeoutCount;  // 超时请求数
    AtomicLong totalCount;    // 总请求数
    // 构造时记录 windowStart，后续只增减计数
}

4.2.2 滑动过程

当新请求到达时，熔断器根据当前时间计算应落入哪个桶：

计算当前时间对应的桶索引：index = (currentTime / bucketSize) % numBuckets
检查该桶的 windowStart 是否等于当前桶的起始时间：

如果相等，直接在该桶上累加计数。
如果不相等（说明时间已滑过该桶的周期），则重置该桶（清空计数，更新 windowStart），然后累加。

统计时，遍历所有桶，累加 windowStart 在 [currentTime - windowLength, currentTime] 范围内的桶数据。

实现要点：桶的“重置”操作是时间窗口的核心。重置时不是删除桶，而是复用桶对象，只清空计数并更新起始时间，避免频繁创建对象导致 GC 压力。

4.3 计数窗口实现原理

计数窗口以请求次数为窗口边界，维护一个固定长度的环形缓冲区（Ring Buffer）或滑动数组。每个元素记录单次请求的结果（成功/失败）。当请求数达到窗口大小时，最旧的请求结果被覆盖。

4.3.1 环形缓冲区实现

// 计数窗口的环形缓冲区简化实现
class CountSlidingWindow {
    int[] buffer;           // 0=成功, 1=失败, 2=超时
    int windowSize;         // 窗口大小，如 100
    int head;               // 当前写入位置
    int count;              // 已记录请求数

    void record(int result) {
        buffer[head] = result;
        head = (head + 1) % windowSize;
        if (count < windowSize) count++;
    }

    double failureRate() {
        int failures = 0;
        int total = Math.min(count, windowSize);
        for (int i = 0; i < total; i++) {
            if (buffer[i] == 1) failures++;
        }
        return (double) failures / total;
    }
}

4.3.2 滑动过程

每个请求到达时，将结果写入 head 指向的位置。
head 指针向前移动一位，超出数组长度则回绕到 0。
当 count < windowSize 时，窗口未填满，统计基于已有数据。
当 count >= windowSize 时，新数据覆盖最旧数据，窗口始终保持最近 N 次请求。

注意：计数窗口在低并发场景下可能长时间不滑动（因为请求数不足），导致熔断器对突发故障的响应延迟。生产环境中通常建议使用时间窗口，或为计数窗口设置最大等待时间兜底。

4.4 滑动窗口在熔断器中的应用

熔断器使用滑动窗口统计错误率或慢调用比例，作为状态转换的决策依据。以时间窗口为例，熔断器的工作流程如下：

请求拦截：每次调用被拦截时，熔断器记录结果（成功/失败/超时）到当前桶。
实时统计：熔断器维护一个滑动窗口，持续计算最近窗口内的错误率。
阈值判断：当错误率超过预设阈值（如 50%），且窗口内请求数达到最小请求数（如 20 次），熔断器从 CLOSED 切换到 OPEN。
半开探测：经过休眠时间后，熔断器进入 HALF_OPEN 状态，允许有限请求通过，并使用新的滑动窗口（或重置原窗口）统计探测结果。
窗口重置：熔断器状态切换时（如从 OPEN 到 HALF_OPEN），滑动窗口通常会被重置，避免旧数据影响新状态的判断。

4.5 时间窗口与计数窗口的对比选型

对比维度	时间窗口	计数窗口
内存开销	固定桶数，与流量无关	固定数组长度，与流量无关
统计精度	受桶数影响，桶越多越精确	受窗口大小影响，窗口越大越精确
低流量适应性	差：窗口内可能无请求，无法触发熔断	好：只要请求数达到窗口大小即可统计
高流量适应性	好：桶按时间均匀分布，统计平滑	差：窗口滑动过快，统计抖动大
实现复杂度	中等：需要处理桶的复用与时间对齐	低：环形缓冲区实现简单
推荐场景	通用场景，尤其是流量波动较大的系统	请求量稳定且对实时性要求高的场景

4.6 参数调优建议

生产实践：Resilience4j 默认使用时间窗口，窗口长度 10 秒，桶数 10。对于大多数微服务场景，这是一个良好的起点。如果系统请求量极低（如每分钟不到 10 次），建议增大窗口长度或改用计数窗口。

窗口长度：建议设置为业务可容忍的最大故障持续时间。例如，如果业务要求 5 秒内感知故障并熔断，窗口长度应 ≤ 5 秒。
桶数：建议 5~20 个。桶数过少导致统计滞后，桶数过多增加内存和计算开销。
最小请求数：时间窗口下必须设置此参数，避免窗口内样本不足导致误熔断。建议值：10~50 次。
计数窗口大小：建议 100~1000 次。过小容易误判，过大延迟熔断响应。

4.7 滑动窗口的边界问题与解决方案

问题	描述	解决方案
桶时间对齐	桶的起始时间与系统时间戳对齐，避免桶漂移	使用 `windowStart = (currentTime / bucketSize) * bucketSize` 强制对齐
并发写入	多个线程同时写入同一个桶导致计数丢失	使用 `AtomicLong` 或 `LongAdder` 保证原子性
统计时窗口滑动	统计过程中桶被重置，导致数据不一致	使用读写锁（ReadWriteLock）或快照方式统计
内存泄漏	桶对象长期不被回收	使用对象池复用桶，避免频繁 new/delete

滑动窗口技术是熔断器实现精确故障统计的基石。理解时间窗口与计数窗口的原理差异，并根据业务流量特征选择合适的实现方式，是熔断器参数调优的第一步。在实际编码中，建议优先采用时间窗口 + 桶复用 + 原子计数的成熟方案，如 Resilience4j 的 SlidingTimeWindow 实现。