3. 核心参数一：滑动窗口类型（基于计数 vs 基于时间）的原理与选择策略

滑动窗口是熔断器统计请求成功/失败数据的核心数据结构。窗口类型决定了熔断器“看多远”以及“如何判断阈值”。生产环境中，选错窗口类型会导致误熔断或熔断不及时。本节深入对比两种主流滑动窗口的实现原理与适用场景。

3.1 两种滑动窗口的核心原理

3.2 基于计数滑动窗口（Hystrix 模式）

Hystrix 使用 “请求数桶” 实现滑动窗口。窗口包含固定数量的桶（如 10 个桶），每个桶记录一定数量的请求。当桶内请求数达到阈值（如 100 次），桶被填满并滑动到下一个桶。

• 优点：实现简单，桶数量固定，内存占用稳定。
• 缺点：低流量时窗口滑动慢，旧数据长期有效，容易导致“延迟熔断”。
• 典型参数：metrics.rollingStats.numBuckets=10，metrics.rollingStats.timeInMilliseconds=10000（10 秒窗口，每个桶 1 秒或 100 次请求）。

3.3 基于时间滑动窗口（Resilience4j / Sentinel 模式）

基于时间的窗口将时间划分为固定长度的“时间片”（如 1 秒）。每个时间片独立统计请求数据。窗口总时长固定（如 10 秒），包含 N 个时间片。每过一个时间片，窗口向前滑动一个片，丢弃最旧的数据。

• 优点：数据新鲜度有保障，低流量下也能及时滑动。
• 缺点：时间片大小需要根据业务 latency 调整，过小会导致统计抖动。
• 典型参数：slidingWindowSize=10（10 秒窗口），slidingWindowType=TIME_BASED，minimumNumberOfCalls=5（最少请求数，防止空窗口误判）。

3.4 滑动窗口结构对比（SVG 架构图）

下图展示两种滑动窗口在 10 秒窗口内的数据组织方式。左侧为基于计数的桶结构，右侧为基于时间的时间片结构。

3.5 选择策略与参数调优建议

选择滑动窗口类型时，需要综合考虑服务流量特征、延迟敏感度和运维复杂度。以下决策树可帮助快速定位：

1. 服务 QPS 是否稳定且高于 100？
   • 是 → 两种窗口均可，基于计数窗口实现更简单。
   • 否 → 优先选择基于时间窗口，避免低流量下数据陈旧。
2. 业务是否对延迟抖动敏感？
   • 是 → 基于时间窗口 + 较小的时间片（如 500ms），提高灵敏度。
   • 否 → 基于计数窗口可接受，桶大小设为 50-100 次请求。
3. 是否需要精确控制熔断恢复时间？
   • 是 → 基于时间窗口，配合 waitDurationInOpenState 精确控制。
   • 否 → 基于计数窗口，依赖请求数自然滑动。

# 基于时间滑动窗口，10 秒窗口，1 秒时间片
slidingWindowType: TIME_BASED
slidingWindowSize: 10
minimumNumberOfCalls: 5
failureRateThreshold: 50
waitDurationInOpenState: 5s

3.6 常见误区与验证方法