企业官网建设流程全解析

学Flink的时候，窗口这块是最容易让人产生“我会了”，结果一上生产又“我不会了”的地方。API就那几个：keyBy之后跟一个window()，选个TumblingEventTimeWindows或者SlidingProcessingTimeWindows，再丢一个聚合函数进去，业务看着就完了。但等数据真的跑起来，乱序、迟到、窗口状态撑爆、下游重复消费，各种问题全冒出来。

这篇文章不打算把官方文档翻译一遍，而是把我实际用 Flink 窗口处理实时指标时沉淀下来的理解写清楚。窗口本质上是一套“给无界数据画边界”的机制，只有把时间语义、触发条件、状态生命周期都搞明白，才算真的会用它，而不是只会抄 Demo。

1. 窗口到底在解决什么问题：无界流的“分段聚合”困境

1.1 无界数据没有“天然的分组边界”

流式计算面对的数据是无穷无尽的，就像一条永远流不完的河。你没办法说“等水停了再统计”，因为水不会停。但业务计算几乎都是要有边界的：每 5 分钟一次接口调用量、每天一个 UV、用户连续 30 分钟没操作就算一次会话结束。这些“每 5 分钟”“每天”“连续 30 分钟”就是人为画出来的边界，Flink 窗口干的就是这件事。

窗口本身不是数据容器，它是时间轴上的一个逻辑区间。每个区间有自己的起始时间、结束时间、里面属于哪些数据，数据到了之后会被分配到对应的区间里，等触发条件满足，就把这个区间里的数据拿出来做一次聚合计算。很多人刚接触窗口时容易有个误解，觉得窗口是内存里一个“筐”，数据先进筐里存着，到点了一口气倒出来。实际上 Flink 窗口更准确地说是一个“状态切片”，每个 key 在每个并行子任务上维护属于自己的窗口状态。

1.2 三类最典型的窗口业务需求

我梳理了自己做过的实时项目，窗口需求基本逃不出下面这三类：

第一类是固定周期统计，比如每 5 分钟统计一次订单金额、每 10 分钟统计一次机房带宽占用。这种需求用滚动窗口，窗口之间不重叠，数据只会落在唯一一个窗口里，统计口径干净，下游最容易对齐。

第二类是滑动窗口监控，比如“实时展示过去 1 小时的故障数”“最近 15 分钟的平均响应时间”。这种“最近 N 分钟”的语义用滑动窗口最合适，窗口重叠，所以边界处的数据会被算进多个窗口，计算结果会有重复，这是业务语义决定的，不是 bug。

第三类是会话分析，比如用户打开 App 之后连续操作，中间隔了 25 分钟没动作，就算一次会话结束。这种“沉默切分”的逻辑没法用固定时间窗口硬切，因为会话长度是不固定的，短的可能几十秒，长的可能一晚上。Flink 的会话窗口就是专门为这种场景设计的。

1.3 理解窗口的五个关键概念

窗口一套完整机制包含五个部分，理解了这五个，后面所有细节就串起来了：

• 窗口分配器：决定每一条数据进哪个窗口，按时间还是按会话间隔切分。
• 窗口函数：窗口触发时对窗口内数据做什么计算，是增量聚合还是全量遍历。
• 触发器：决定窗口什么时候算完、什么时候输出结果，是可以自定义的“闹钟”。
• 驱逐器：在窗口函数执行前，能先踢掉一部分数据，比如去掉异常极值。
• 状态与清理：窗口状态什么时候保留、什么时候删除，和迟到数据机制直接相关。

后面我会把这五个概念挨个拆开讲，尤其注意窗口函数的选型和触发器的行为，这是生产上最容易埋坑的地方。

2. 你选的到底是“哪个时间”？事件时间与处理时间的差异是窗口的地基

2.1 三个时间戳，先别搞混

Flink 里一共有三个时间概念，很多人窗口写错了，根子就在这三个时间上没拎清：

先说结论：**只要数据里带业务时间字段，就老老实实用事件时间，别图省事用处理时间。**处理时间在数据源稳定、吞吐不高的小任务里看着挺正常，但只要数据一积压，问题立刻暴露。

2.2 一个实际场景：处理时间为什么害人

举个我踩过的例子。之前有一个实时订单统计任务，统计口径本来应该按照“订单创建时间”归属到对应小时窗口，结果最初实现的人图省事用了处理时间窗口。平时业务量小看不出来，有一次数据源凌晨积压了三个小时的延迟，早上 8 点才开始追数据，所有凌晨的订单全部被算进了早上 8 点到 9 点的窗口里。凌晨的运营看板数据空缺，早上的数据虚高，业务方拿着这个结果复盘，差点闹出乌龙。那个任务后来全部改成了事件时间，再没出过同类问题。

之所以这样，是因为处理时间窗口用的是“数据到达算子那一刻的机器时间”，数据几点到就算几点的账，和业务真实发生时间无关。而事件时间窗口用的是数据自带的时间戳，哪怕这条数据迟到了三个小时，它依然会被正确地归入凌晨的那个小时窗口，前提是你把水位线和迟到机制配好。

2.3 怎么给数据指定事件时间

在 DataStream API 里，通过assignTimestampsAndWatermarks方法指定从哪条字段提取事件时间：

DataStream<OrderEvent> stream = env .addSource(kafkaSource) .assignTimestampsAndWatermarks( WatermarkStrategy.<OrderEvent>forBoundedOutOfOrderness(Duration.ofSeconds(10)) .withTimestampAssigner((event, ts) -> event.getOrderTime()) );

代码很简单，但要注意一个关键问题：**event.getOrderTime()返回的是毫秒时间段还是秒级时间戳。**我见过不止一次，时间戳没换算对，导致窗口时间差了 1000 倍，窗口要么全挤到一个区间里，要么一直不触发。如果业务数据库里存的是2025-01-01 10:00:00这种字符串，记得先解析成Instant或毫秒长整型，再传给时间戳分配器。

事件时间是窗口的地基，这个选错，后面窗口类型选得再合理都是白搭。

3. 滚动、滑动、会话、全局：四种窗口怎么选才对

3.1 滚动窗口：最简单的聚合边界

滚动窗口按固定时间长度切分，窗口之间不重叠，每条数据只会进一个窗口。假设窗口大小 5 分钟，那么数据只可能落在[10:00, 10:05)、[10:05, 10:10)这样的区间里，边界处的数据归属前一个还是后一个窗口由左闭右开决定。

DataStream<OrderEvent> keyedStream = stream.keyBy(e -> e.getUserId()); keyedStream .window(TumblingEventTimeWindows.of(Time.minutes(5))) .aggregate(new OrderAmountAggregate()) .print();

适合滚动窗口的场景：每 5 分钟统计订单量、每分钟统计日志条数、每天统计 UV。这类需求没有“最近 N 分钟”的滑动语义，窗口边界固定，输出频率固定，下游做报表对齐最容易。

3.2 滑动窗口：算“最近 N 分钟”的唯一解

滑动窗口有两个参数：窗口大小和滑动步长。窗口大小决定你要算“多长一段”的数据，滑动步长决定“隔多久输出一次”。比如窗口大小 1 小时，滑动步长 5 分钟，意思就是每 5 分钟输出一次，每次输出的是过去 1 小时的数据。

keyedStream .window(SlidingEventTimeWindows.of(Time.hours(1), Time.minutes(5))) .aggregate(new AbnormalCountAggregate());

滑动窗口的数据会重复计算。一条 10:02 的数据，会同时出现在[09:05, 10:05)、[09:10, 10:10)等多个窗口里。这是滑动语义自带的，不算 bug，但你要知道一个性能指标：窗口总数 = 窗口大小 / 滑动步长。窗口大小 1 小时、滑动步长 1 分钟，那就同时存在 60 个窗口在跑。如果 key 维度又特别多，每个 key 都要维护 60 份窗口状态，这个倍数关系会直接影响内存和性能。同类需求如果对“实时性”要求不那么苛刻，可以考虑改成一个小时滚动窗口加 5 分钟的延迟重算，生产环境能省不少资源。

3.3 会话窗口：用“沉默”来切分数据

会话窗口不是按固定时间切，而是按照“数据之间隔了多久没来”来切。假设会话间隔设为 30 分钟，那么两条数据之间如果间隔超过 30 分钟，就认为前一个会话结束，后一个数据开一个新会话。

keyedStream .window(EventTimeSessionWindows.withGap(Time.minutes(30))) .process(new SessionProcessFunction());

会话窗口特别适合用户行为分析：一个用户从打开 App 到离开，中间可能操作了很久，也可能中途停了好久再继续。固定窗口没法表达这种“连续一段操作”的概念，会话窗口天然匹配这种“活跃段”的切分。会话间隔还可以做成动态的：DynamicEventTimeSessionWindows的withDynamicGap可以按 key 或按事件内容返回不同的 gap 值。比如普通用户 30 分钟算一次会话，VIP 用户 1 小时才算会话断开。

3.4 全局窗口：能不用就不用

全局窗口把所有数据放进同一个窗口，永远不自动触发。必须配合自定义Trigger使用，比如你攒满 1 万条数据触发一次计算，或者每个小时手动触发一次。全局窗口绕过了所有时间边界，等于把“窗口什么时候触发”这件事完全交给你自己，灵活性最大，但要自己负责语义和状态清理，稍有不慎就把内存吃满。正式项目里我很少用，除非是做一些内存批次聚合的特殊场景。

四种窗口的选择其实可以总结成一句话：**数据要不要重叠，按什么依据切分。**重叠选滑动，不重叠按时间选滚动，按不活动间隔选会话，什么规则都不想定就选全局加自定义触发。用这个思路去套业务需求，基本不会选错。

4. 窗口从生到死的完整链路：分配、计时、触发、计算

4.1 keyBy 之后，每个 key 各自维护自己的窗口

窗口操作的前面通常跟着keyBy。做keyBy之后，整个流被拆成 n 个逻辑子流，**同一个 key 的数据一定会被分到同一个并行子任务上，而每个 key 都有自己独立的一份窗口状态。**这一点非常关键：窗口是按 key 隔离的，不是全局共用一个窗口。假如你按用户 ID 分组，每个用户都各自维护自己的时间窗口，一万个用户就有一万份并行的窗口状态。

如果你不写keyBy，直接对 DataStream 调windowAll()，那整个并行度就是 1，所有数据都挤在一个窗口里计算，吞吐直接废掉。windowAll一般只用于全局统计，比如全站每 5 分钟的总访问量，业务上允许单点瓶颈才用它。

4.2 窗口分配器如何确定数据属于哪个窗口

窗口分配器做的事情，本质上是一次“时间取模”计算。以TumblingEventTimeWindows为例，窗口大小为 5 分钟，即 300000 毫秒，那么 Flink 会计算：

windowStart = timestamp - (timestamp + offset) % size windowEnd = windowStart + size

也就是说，只要给了一条数据的事件时间，Flink 就能算出它的窗口起点和终点。所有拥有相同windowStart和windowEnd的数据，都被放进同一个窗口对象里，窗口对象在内部由一个TimeWindow(start, end)表示。所以窗口在 Flink 底层不是一个物理上的大容器，更像是一个“区间标记”，数据分散存储在状态里，窗口触发时再把对应区间的数据收集起来计算。

这个设计带来的一个好处是，窗口的合并非常自然。会话窗口就是靠这个能力实现的：如果两个相邻会话窗口之间的间隔小于 gap 值，Flink 会自动把它们 merge 成一个更大的窗口，不需要用户手动处理。

4.3 窗口函数选型：增量聚合还是全量收集

窗口触发时执行的计算逻辑，由窗口函数决定。窗口函数有两种截然不同的执行思路，选错会在性能上付出代价：

增量聚合函数，包括ReduceFunction和AggregateFunction，它们的特点是“来一条算一条”。数据进入窗口时，计算结果就同步更新，窗口触发时直接把中间结果输出。窗口内不保留原始数据，内存开销小，实时性好，绝大多数统计场景都应该用这一类。

// AggregateFunction 的泛型：输入类型、累加器类型、输出类型 keyedStream .window(TumblingEventTimeWindows.of(Time.minutes(5))) .aggregate(new AggregateFunction<OrderEvent, Long, Long>() { @Override public Long createAccumulator() { return 0L; } @Override public Long add(OrderEvent value, Long accumulator) { return accumulator + value.getAmount(); } @Override public Long getResult(Long accumulator) { return accumulator; } @Override public Long merge(Long a, Long b) { return a + b; } });

全量窗口函数ProcessWindowFunction，则是先把窗口内所有数据缓存下来，等窗口触发时一次性遍历全部数据做计算。它能拿到完整的上下文信息，包括窗口起止时间、当前 watermark、并行子任务编号等，能做增量函数做不了的复杂计算，比如排序、取 Top N、计算中位数。

keyedStream .window(TumblingEventTimeWindows.of(Time.minutes(5))) .process(new ProcessWindowFunction<OrderEvent, String, String, TimeWindow>() { @Override public void process(String key, Context context, Iterable<OrderEvent> elements, Collector<String> out) { long count = 0L; for (OrderEvent e : elements) { count++; } out.collect(key + ": " + count); } });

如果一定要取 Top N 这种全量逻辑，又要避免数据量太大占满内存，推荐用aggregate(AggregateFunction, ProcessWindowFunction)组合：增量函数做粗粒度聚合，把窗口内的数据先压缩成小集合，然后 ProcessWindowFunction 只接收这个小集合，内存压力小得多。这个组合是我做实时 Top N 任务的标准写法。

4.4 窗口的触发时刻由谁决定

窗口不是一到了 end time 就自动计算。真正决定窗口是否触发的是触发器。事件时间窗口默认用EventTimeTrigger，它的逻辑很简单：当 watermark 超过窗口的 end time 时触发计算。这个设计把“窗口什么时候算完”和“数据完整到什么程度”绑在了一起，所以 watermark 推进的快慢直接影响窗口出结果的延迟。

这一块我放到下一章细讲，因为它是整个窗口机制里最容易出问题，也最需要调参的地方。

5. 水位线才是决定窗口“何时关门”的关键

5.1 水位线的本质是一条“数据完整性估计线”

Watermark 是 Flink 事件时间处理的核心概念，你可以把它理解成一句话：“在这条标记之前的数据，我都应该已经收到了。”它不是真实时间，而是数据流里传递的一个特殊标记，用来告诉下游算子：我的数据收集到什么进度了。

我常用一个开会等迟到来宾的例子解释 watermark。你组织一个 10:00 的会，大多数人都到了，但总有人迟到。你不能永远等下去，所以定了个规矩：10:05 还不来就默认他不来了，会议照常开始。这个 10:05 就是 watermark，5 分钟是乱序容忍度。如果一个人 10:03 到了，他还能赶上；如果 10:06 才到，会议已经开始，他就是迟到数据。watermark 就是流里的“会议开始时刻”，它决定了窗口等不等、等到什么时候。

5.2 多并行度下，watermark 以最小的那个为准

流经过多个并行子任务后，watermark 的传播有一个对齐机制：下游算子接收各个上游子任务的 watermark，取最小值作为当前有效水位。如果一个上游子任务的数据源卡了 5 分钟没发数据，它的 watermark 一直不前进，那么下游所有窗口都会被它拖住，迟迟不触发。

这就是为什么很多生产任务里需要设置空闲流超时：

WatermarkStrategy.<OrderEvent>forBoundedOutOfOrderness(Duration.ofSeconds(10)) .withIdleness(Duration.ofSeconds(30));

withIdleness表示某个数据源分区超过 30 秒没新数据，就忽略它的 watermark，不让它拖累整体进度。数据源偶尔断流、kafka 分区不太均衡的任务，一定要加上这个参数。

5.3 乱序容忍度怎么设：不是越小越好

forBoundedOutOfOrderness(Duration.ofSeconds(10))里的 10 秒表示允许数据最多乱序 10 秒。这个值设得越小，窗口触发越早，延迟越低，但乱序超过这个值的数据会被丢弃，准确率下降；设得越大，等得越久，准确率提高但结果出来得越慢。

我的做法是先做一段数据探查。把真实数据里的时间戳和到达时间做一个差值统计，看 P95 和 P99 的延迟分布，然后按照“覆盖 95% 到 99% 的数据”来设置乱序容忍度。如果业务要求结果必须准时，可以不追求覆盖 99% 的数据，让少数极端迟到数据走侧输出，另做补偿。如果不做探查，拍脑袋设一个 10 秒，可能正好卡在 P50 附近，表现为“任务偶尔丢数据”，调起来非常被动。

5.4 watermark 太激进或太保守的两种故障表现

watermark 太激进（乱序容忍度太小），数据经常追不上，表现为“统计数字偏小”“窗口输出后又收到数据但被丢弃”。

watermark 太保守（乱序容忍度太大），窗口迟迟不触发，表现为“结果延迟严重”“一个 1 分钟窗口要等 5 分钟才出结果”。

这两种问题光看 Flink UI 不容易发现，最直接的办法是给每个窗口的触发时间打日志。窗口触发时打印 watermark 和窗口 end time 的差值，连续观察一段时间，就能摸清稳定的量级。这个习惯帮我排查过至少三个“窗口不准”的任务，比对着源码猜快得多。

6. 迟到数据：三种处理策略和我的真实取舍

6.1 什么是“迟到数据”

严格来说，窗口已经触发计算之后、数据才到达，这种数据就是迟到数据。比如窗口 end time 是 10:05，watermark 已经涨到 10:06，窗口触发并输出了结果，这时候一条时间戳为 10:04 的数据才姗姗来迟。它属于已经计算过的窗口，但来晚了。

迟到的原因通常有几个：网络传输抖动、上游业务系统发送延迟、Kafka 分区消费速度不均衡、消费者进程长时间 GC。真实环境里完全杜绝迟到基本不可能，重要的是想清楚迟到之后怎么办。

6.2 策略一：默认行为，直接丢弃

什么都不配的情况下，迟到的数据会被直接丢弃。这是最省事但也是准确率最低的方案。适合那些对精确性不敏感、只看趋势的看板类任务，比如实时监控大屏上的流量趋势，少几条对整体走势影响不大。

6.3 策略二：allowedLateness，让窗口晚点关门

通过allowedLateness(Duration.ofMinutes(5))可以让窗口在触发后继续保留一段时间。这期间来到的迟到数据，会再次触发窗口计算，输出修正后的新结果。

keyedStream .window(TumblingEventTimeWindows.of(Time.minutes(5))) .allowedLateness(Duration.ofMinutes(1)) .aggregate(new OrderAmountAggregate());

这里有几个细节容易踩坑：

第一，结果是多次触发的。窗口第一次触发输出一个值，后面每来一条迟到数据，都会触发一次新的输出。下游如果是写入数据库，重复写入会成为问题，必须配合幂等键或更新语句去重。上游 Kafka 到下游数据库这条链路里，我一般都建议用主键更新语义，比如INSERT ... ON DUPLICATE KEY UPDATE。

第二，窗口状态不会立刻清理。使用了allowedLateness之后，窗口状态要保留到“窗口 end time + allowedLateness”，确保所有可能在允许时间内的迟到数据都能被处理。窗口数量多、key 数量大的任务，状态保留时间会明显变长，要注意压状态大小。

6.4 策略三：sideOutputLateData，迟到数据走单独通道

如果你既不想让迟到数据污染主结果，又不想让它们被白白丢掉，可以先把迟到数据送入侧输出流，后面再做补偿处理。

OutputTag<OrderEvent> lateTag = new OutputTag<OrderEvent>("late-events") {}; SingleOutputStreamOperator<Long> mainStream = keyedStream .window(TumblingEventTimeWindows.of(Time.minutes(5))) .sideOutputLateData(lateTag) .aggregate(new OrderAmountAggregate()); DataStream<OrderEvent> lateStream = mainStream.getSideOutput(lateTag);

侧输出流里的数据不会进入主结果，你可以单独消费，做异步重算、写明细表、或者发到告警系统。这种方式把“正常结果结果”和“补偿数据”彻底分开了，语义最干净，但实现上要多维护一套下游处理逻辑。

6.5 我的选择：一般任务用 allowedLateness，对账任务用侧输出

真实项目里，我把这两条策略当两个档位用：

普通实时指标，比如实时大屏、实时经营看板，用allowedLateness(1分钟或2分钟)，配合幂等写入。好处是大部分乱序数据都能被修正，结果延迟也不高。

对账类任务，比如订单金额核对、实物库存调整，对准确性要求极高，主结果保持准时输出，所有迟到数据必须走sideOutputLateData，每天再跑一个离线批任务把侧输出数据合并进去，确保最终对平。两条路互不干扰，主任务延迟低，侧输出负责兜底。

这里还有个容易被忽略的点：**当你同时用了allowedLateness和窗口函数是ProcessWindowFunction时，迟到数据会重复执行整个 process 方法。**如果 process 方法里有写外部系统的副作用，比如在窗口结束时发了个 HTTP 请求，那迟到数据触发时又会发一次。解决的办法是在 process 方法里判断当前窗口是否已经触发过，或者把外部操作做成幂等。

7. 进阶：自定义 Trigger 和 Evictor，窗口计算的“手动挡”

7.1 Trigger 的五个生命周期回调

默认触发器帮我们处理了大部分场景，但总有需要“手动挡”的时候。比如一个交互式大屏，希望窗口数据只要你攒到 500 条就立刻展示，而不必等窗口 end time。Flink 的Trigger接口提供四个核心回调方法：

• onElement()：每条数据进入窗口时调用，可以决定要不要立刻触发。
• onProcessingTime()：基于处理时间的定时器触发时调用。
• onEventTime()：基于事件时间的定时器触发时调用，EventTimeTrigger 就是在这里判断 watermark 是否越过 end time。
• onMerge()：两个窗口合并时调用，主要处理会话窗口的场景。
• clear()：窗口被清理时调用，用来删除定时器和状态。

每个方法的返回值可以是CONTINUE（继续等）、FIRE（触发计算但不清理窗口）、PURGE（清理窗口但不计算）、FIRE_AND_PURGE（先计算再清理）。默认的EventTimeTrigger只会返回FIRE，所以窗口触发后状态还保留着，配合allowedLateness才能处理迟到数据。

7.2 一个自定义 Trigger 的实际例子

下面这个自定义触发器的需求是：窗口数据达到 100 条就提前输出一版，窗口 end time 到了再输出最终一版并清理窗口。

public class CountOrTimeTrigger extends Trigger<OrderEvent, TimeWindow> { private final long maxCount; public CountOrTimeTrigger(long maxCount) { this.maxCount = maxCount; } @Override public TriggerResult onElement(OrderEvent element, long timestamp, TimeWindow window, TriggerContext ctx) throws Exception { // 注册窗口结束时的定时器 ctx.registerEventTimeTimer(window.maxTimestamp()); // 每来一条数据，检查当前这个窗口累计了多少条 ValueState<Long> countState = ctx.getPartitionedState(new ValueStateDescriptor<>("count", Long.class)); long count = countState.value() == null ? 0L : countState.value(); count++; countState.update(count); if (count >= maxCount) { // 提前触发，但不清理窗口，后面还能追加计算 return TriggerResult.FIRE; } return TriggerResult.CONTINUE; } @Override public TriggerResult onEventTime(long time, TimeWindow window, TriggerContext ctx) throws Exception { if (time >= window.maxTimestamp()) { // 窗口真正结束，计算并清理 return TriggerResult.FIRE_AND_PURGE; } return TriggerResult.CONTINUE; } @Override public TriggerResult onProcessingTime(long time, TimeWindow window, TriggerContext ctx) throws Exception { return TriggerResult.CONTINUE; } @Override public void clear(TimeWindow window, TriggerContext ctx) throws Exception { // 清理状态和定时器 ctx.deleteEventTimeTimer(window.maxTimestamp()); ctx.getPartitionedState(new ValueStateDescriptor<>("count", Long.class)).clear(); } }

这里有个容易忽略的坑：提前触发 FIRE 时，不会调用 clear()，窗口状态还在。如果每次提前触发都往外部系统写数据，那么同一个窗口会输出多份“阶段性结果”。我在实际使用时会根据结果字段加一个版本或序号，下游只认最后一份。

7.3 Evictor：计算前把不需要的数据踢掉

Evictor 在触发器触发之后、窗口函数执行之前介入，负责从窗口元素中移除一部分数据。默认的窗口操作不执行任何 evict。自定义 Evictor 最常见的场景是去掉数据中的极端值。比如你们在统计响应时间的平均值，有一两条数据因为 GC 停顿导致延迟高达 10 秒，把均值拉高了很多，你可以在计算前先把最大最小的几个值剔除。

keyedStream .window(TumblingEventTimeWindows.of(Time.minutes(5))) .trigger(new CountOrTimeTrigger(100)) .evictor(new Evictor<OrderEvent, TimeWindow>() { @Override public void evictBefore(Iterable<TimestampedValue<OrderEvent>> elements, int size, TimeWindow window, EvictorContext evictorContext) { // 计算前剔除，剔掉前1和后1个极值 } @Override public void evictAfter(Iterable<TimestampedValue<OrderEvent>> elements, int size, TimeWindow window, EvictorContext evictorContext) { // 计算后剔除，用得少 } });

Evictor 的使用代价不低：它强制 Flink 先把窗口内所有数据缓存下来，驱逐完再做计算，导致之前提到的“增量聚合”优化全部失效。只有在数据量和窗口时间都比较可控的场景下才建议用，超大窗口叠加自定义 Evictor，基本就是内存溢出的前兆。

7.4 一句话建议：别滥用自定义 Trigger 和 Evictor

自定义触发器最大的价值是让“提前输出”和“最终输出”两套逻辑共存。但每一次触发都意味着下游多了一次写操作，多次触发再加上组合使用的 Evictor，会让系统复杂度和故障概率同步上升。能用默认触发器解决的，就别自己造轮子。我见过一个项目为了“数据满 1000 条就提前看一眼”的需求，自定义触发器里还注册了 processing time 定时器，结果窗口状态清理逻辑写漏了，内存涨到直接 OOM。这种自定义逻辑一定要把clear()里删定时器和清状态写完。

8. 生产环境里最常踩的窗口坑

8.1 滑动窗口带来的窗口数量爆炸

之前提到过，窗口总数等于窗口大小除以滑动步长。这个比例关系在小数据量下不明显，但在高吞吐任务里是致命的。举个例子：一个订单流按用户 ID keyBy，用户数有 10 万，你开了一个“窗口大小 1 小时、滑动步长 1 秒”的窗口，那同时存在的窗口数量是 3600 个，每个用户每个窗口都有一份状态，状态总量是 10 万用户乘以 3600 个窗口，这个规模对内存的消耗是灾难级的。

优化思路有两种：一是改窗口大小和步长比例，比如 1 小时窗口 5 分钟步长，窗口数量降到 12 个；二是彻底换一种实现方式，用滚动窗口存原始聚合值，下游再手动对多个滚动窗口做合并计算，相当于把滑动计算压力转移到读写端。基于自己业务的实时性要求，后一种方案在很多场景里都能显著降低 Flink 端压力。

8.2 allowedLateness 设太大，下游重复数据堆积

有段时间我把一个交易统计任务的allowedLateness设成了 30 分钟，想着“宁可多等等也不能漏数据”。结果每天凌晨高峰期，下游数据库的写入量是白天的好几倍。因为每个窗口在 30 分钟内每收到一条迟到数据就触发一次更新，同一个 key 被反复写，数据库压力直接拉爆。

后面我把策略调整成：主结果延迟输出用allowedLateness控制在 1 分钟内，极端迟到的数据走侧输出，每天单独跑一个批量补偿。这样下游压力降下来了，对账也清晰，告警数据不会因为重复写入而抖动。

8.3 key 规模过大时的状态膨胀

Flink 窗口状态是“key 数 × 窗口数 × 单窗口状态量”。这里的 key 如果是一个高基数字段，比如设备 ID 或订单号，状态膨胀速度会非常惊人。

缓解手段我常用三个：

• 提前做一次预聚合：在窗口操作之前，先按分钟或按小时做一次增量聚合，收敛数据量，再上大窗口。
• 设置状态 TTL：给窗口状态配置StateTtlConfig，让超时数据自动过期，避免状态无限增长。
• 改用 SQL 语义的 Group Aggregation：如果业务对窗口边界不敏感，Flink SQL 的 group by 窗口内部做了不少状态复用和优化，比手动 DataStream 窗口省心一些。

8.4 ProcessWindowFunction 全量收集导致内存溢出

窗口内数据量极大时，直接上ProcessWindowFunction很容易出现堆内存暴涨。一个 10 分钟的窗口，高峰时期可能要缓存几百万条数据，光靠堆内存扛不住。

最优解是增量聚合加全量聚合组合使用。先用AggregateFunction把窗口数据聚合成一个紧凑的中间结构，再交给ProcessWindowFunction做最终输出。这样缓存的数据量从“全量明细”变成“少量中间结果”，内从根上消掉了。具体代码参考第四章，我这里想强调的是：从设计上就要避免在 window function 里保留明细数据，而不是等内存溢出了再调参数。

8.5 外部存储写入的幂等性

只要是窗口多次触发，下游写入就必须具备幂等性。这个坑我踩过不止一次，具体表现是：同一笔订单的金额被统计了两次，或者同一个窗口的聚合结果被更新成两个不同的值。窗口重试、重启、迟到数据触发，都会导致重复写入。

解决思路是：写入数据库时用唯一键，比如窗口 start + end + key 作为主键；写入消息队列时，下游消费端做去重；写入 HDFS/对象存储时，文件名包含窗口起止时间，让任务重启后能覆盖而不是追加。Flink 本身提供了 checkpoint，能够保证“精确一次”状态一致性，但它管不到外部系统，所以幂等设计必须在业务侧做。

8.6 事件时间字段的合法性检查

最后提一个最不起眼、也最容易翻车的点：事件时间字段可能是 0 或者是未来时间。有些业务系统拿不到正确时间时会填默认值 0，或者测试数据带了未来一个月的时间戳，在 Flink 里会导致 watermark 瞬间上涨到一个离谱的值，然后整条流的窗口全部提前触发，数据结果全乱。

我现在的做法是在 Source 端或者时间戳分配器之前，加一个简单的数据清洗算子，把时间戳为 0、为负、超过当前时间 24 小时的数据过滤掉或者打到 side output，单独排查。这个小小的前置检查，省了我大量排障时间。

回头看我最早写窗口代码的时候，最难的不是那几个 API，而是脑子里缺一张窗口从分配到触发的完整时序图。后来养成一个习惯：每个窗口任务上线前，先在测试环境把 watermark、触发时间、迟到数据量打成日志，跑个半天观察曲线，再决定allowedLateness和乱序容忍度调成多少。窗口这套机制，靠背 API 学不会，靠生产环境踩坑又太贵，最好的方式就是带着这张时序图去理解每个参数背后的代价，然后再动手写代码。