📚 课程目录第2章时间窗口与滑动窗口

2、时间窗口与滑动窗口：固定窗口、滑动窗口、会话窗口的原理与实现

说到实时指标聚合，窗口机制是绕不开的核心。我刚开始接触流计算时，觉得窗口不就是「切一段数据算一下」嘛，有啥复杂的？后来在生产环境被坑了几次，才明白窗口选型直接决定了你的聚合结果准不准、延迟高不高。

今天咱们就把三种主流窗口——固定窗口、滑动窗口、会话窗口——掰开揉碎讲清楚。我会结合自己的踩坑经历，帮你避开那些文档里不会写的雷区。

2.1 固定窗口（Tumbling Window）

固定窗口也叫滚动窗口。它的特点是：窗口之间不重叠，数据只属于一个窗口。就像切蛋糕，一刀下去，每块都是独立的。

核心特征：

窗口大小固定（比如 5 分钟、1 小时）
窗口之间首尾相接，没有重叠
每条数据只属于一个窗口
天然适合做「按时间段统计」的场景

举个例子。假设我们要统计每 5 分钟的 API 请求量。时间从 10:00 开始，那么窗口就是 [10:00, 10:05)、[10:05, 10:10)、[10:10, 10:15)……10:03 来的请求落在第一个窗口，10:07 来的落在第二个窗口，清清楚楚。

实现思路其实很简单：

// 伪代码：固定窗口聚合
function assignToWindow(eventTime, windowSizeMs) {
    // 用时间戳除以窗口大小，取整
    let windowStart = Math.floor(eventTime / windowSizeMs) * windowSizeMs;
    return windowStart;
}

// 比如 eventTime = 10:03:00 的时间戳
// windowSizeMs = 5 * 60 * 1000 = 300000
// windowStart = Math.floor(10:03:00 / 300000) * 300000 = 10:00:00

我在项目中遇到过一个问题：固定窗口的边界处理。比如窗口是 [10:00, 10:05)，那 10:05:00 这个请求算哪个窗口？不同系统的处理方式不一样。有的算前一个，有的算后一个。我个人习惯统一用「左闭右开」区间，也就是 [start, end)，这样 10:05:00 就归到 [10:05, 10:10) 这个窗口。团队里统一约定好，能省掉很多排查时间。

适用场景：

按小时/分钟统计的报表
周期性监控指标（如每 5 分钟的平均 CPU 使用率）
计费系统中的时段用量统计

2.2 滑动窗口（Sliding Window）

滑动窗口和固定窗口最大的区别是：窗口之间有重叠。你可以想象一个放大镜，每隔一小段距离就停下来看一下，每次看到的范围是固定的，但观察位置在移动。

滑动窗口有两个关键参数：

窗口大小（Window Size）：每个窗口覆盖的时间范围
滑动步长（Slide Interval）：窗口向前移动的间隔

举个例子。窗口大小 10 分钟，滑动步长 1 分钟。那么窗口序列就是 [10:00, 10:10)、[10:01, 10:11)、[10:02, 10:12)……你想想看，10:05 这个时间点，会同时出现在多少个窗口里？答案是 10 个（从 [10:00, 10:10) 到 [09:56, 10:06) 都包含它）。

为什么需要滑动窗口？ 因为固定窗口的边界太「硬」了。比如你监控系统每 5 分钟的平均延迟，如果刚好在窗口边界附近发生了一次抖动，固定窗口可能把这次抖动「切」成两半，两边看起来都不严重。滑动窗口因为重叠，能更平滑地反映变化趋势。

实现上，滑动窗口有两种常见方式：

// 方式一：基于时间轮（适合步长较小的情况）
class SlidingWindowTimeWheel {
    constructor(windowSize, slideInterval) {
        this.buckets = new Array(windowSize / slideInterval);
        this.currentIndex = 0;
    }
    
    add(event) {
        // 把事件加到当前桶
        this.buckets[this.currentIndex].add(event);
        // 聚合时，把所有桶的数据合并
    }
    
    slide() {
        this.currentIndex = (this.currentIndex + 1) % this.buckets.length;
        this.buckets[this.currentIndex].clear(); // 清空最旧的桶
    }
}

// 方式二：基于优先队列（适合步长较大的情况）
// 维护一个按时间排序的事件队列
// 每次滑动时，移除过期事件，加入新事件

我记得有一次做实时风控系统，要求统计「过去 5 分钟内每个用户的登录失败次数」，滑动步长是 30 秒。一开始我用的是方式一（时间轮），因为步长小、窗口大，桶的数量很多（5 分钟 / 30 秒 = 10 个桶），性能还不错。但如果窗口大小是 1 小时、步长是 1 秒，桶数就变成 3600 个，这时候时间轮的内存开销就大了，得改用方式二。

避坑指南：

我曾经在生产环境遇到过一个问题：滑动窗口的「边界效应」。比如窗口大小 10 分钟，步长 1 分钟，理论上每个窗口有 10 个桶的数据。但如果数据延迟到达，或者系统时钟有偏差，某些桶可能还没填满就被滑出去了。结果就是窗口聚合值忽高忽低。

解决办法：实现时加上「水位线」（Watermark）机制，确保所有数据都到达后再触发窗口计算。或者用「允许延迟」参数，给迟到的数据一个缓冲期。

2.3 会话窗口（Session Window）

会话窗口和前两种完全不同。它不按固定的时间长度来切分，而是根据数据的「活动间隙」来划分。说白了就是：如果一段时间内没有新数据来，就认为当前会话结束了，开始一个新的会话。

会话窗口只有一个关键参数：会话超时时间（Session Gap）。比如超时时间设为 30 分钟。用户 10:00 点了一次按钮，10:05 又点了一次，10:20 再点一次——这些都在 30 分钟内，属于同一个会话。如果用户下次操作是 11:00，距离上次已经超过 30 分钟，那就开启一个新会话。

实现起来比固定窗口和滑动窗口复杂一些：

// 伪代码：会话窗口合并逻辑
class SessionWindow {
    constructor(sessionGapMs) {
        this.gap = sessionGapMs;
        this.sessions = new Map(); // userId -> {start, end, events}
    }
    
    addEvent(userId, eventTime) {
        let session = this.sessions.get(userId);
        if (!session) {
            // 新用户，创建新会话
            session = { start: eventTime, end: eventTime, events: [] };
            this.sessions.set(userId, session);
        } else if (eventTime - session.end <= this.gap) {
            // 在超时时间内，合并到当前会话
            session.end = eventTime;
        } else {
            // 超时了，先触发旧会话的聚合，再创建新会话
            this.triggerAggregation(userId, session);
            session = { start: eventTime, end: eventTime, events: [] };
            this.sessions.set(userId, session);
        }
        session.events.push(eventTime);
    }
}

你可能会问：会话窗口到底有什么用？我举几个实际场景：

用户行为分析：用户在电商网站的一次浏览会话，从进入网站到离开，中间可能有多次点击、搜索、加购。用会话窗口可以把这些操作归到一次「访问」里。
异常检测：某个 IP 在短时间内发起大量请求，如果超过会话超时时间还在持续，可能就是攻击行为。
日志聚合：微服务的一次请求链路，可能跨多个服务、产生多条日志。用会话窗口可以把这些日志归到一次「调用」里。

会话窗口的注意事项：

会话超时时间的选择很关键。太短会把正常操作切碎，太长又会把多次独立操作合并到一起。我一般建议先根据业务经验设一个初始值，然后通过历史数据统计分析来调整。
会话窗口的状态维护成本较高。如果用户量很大（比如千万级），每个用户都要维护一个会话状态，内存压力不小。可以考虑用 Redis 等外部存储来保存会话状态。

2.4 三种窗口对比

维度	固定窗口	滑动窗口	会话窗口
窗口是否重叠	否	是	否（但动态创建）
窗口大小	固定	固定	动态（由数据决定）
触发条件	时间到达	时间到达	数据间隙超时
实现复杂度	低	中	高
内存开销	低	中（取决于桶数）	高（取决于活跃会话数）
典型场景	周期性报表	实时监控、趋势分析	用户行为、异常检测

2.5 窗口实现的核心挑战

不管哪种窗口，在实际落地时都会遇到几个共性问题。我简单说一下：

乱序数据：数据到达的顺序不一定和事件发生的时间一致。比如网络延迟，10:05 发生的事件可能 10:06 才到。如果窗口已经计算完了，这个事件就丢了。解决办法是用水位线（Watermark）机制，允许一定程度的延迟。
状态管理：窗口需要维护中间状态（比如当前窗口的累加值）。如果系统崩溃重启，状态就丢了。生产环境一般会用 Checkpoint 机制定期保存状态到外部存储（如 HDFS、Redis）。
性能优化：滑动窗口的桶数太多时，每次滑动都要重新聚合所有桶的数据，计算量很大。优化思路是「增量聚合」——只计算新加入的数据和移除的数据，而不是全量重算。

我的建议：

刚开始做实时聚合时，别一上来就上滑动窗口或会话窗口。先试试固定窗口，把基础逻辑跑通。等遇到「固定窗口不够用」的场景时，再切换到更复杂的窗口类型。这样你的系统演进路径会更平滑，排查问题也更容易。

2.6 三种窗口的关系图

下面这张图展示了三种窗口的核心区别。你可以直观地看到数据是如何被分配到不同窗口中的。

嗯，三种窗口的原理和实现就讲到这里。固定窗口最简单，适合周期性统计；滑动窗口能平滑反映趋势，但要注意性能和边界问题；会话窗口最灵活，适合用户行为分析，但状态管理成本高。实际项目中，我经常是三种窗口混着用——比如用固定窗口做小时报表，用滑动窗口做实时监控，用会话窗口做用户画像。关键是根据业务场景选对工具，别为了炫技而用复杂的方案。