1. 窗口计算延迟概述

大家好，我是老张。做实时计算这些年，我踩过最多的坑，就是窗口计算延迟。今天咱们先把这个概念彻底聊透。

窗口计算延迟，说白了就是——数据从进入系统，到窗口计算完成输出结果，这中间等了多久。你想想看，实时系统要是等太久，那还叫实时吗？

1.1 什么是窗口计算延迟

窗口计算，就是把无限流数据切成有限的时间段来处理。比如每5分钟统计一次订单量，每10秒计算一次平均温度。但问题是，切窗口本身就需要时间，处理数据也需要时间，这些时间加起来，就是延迟。

我举个例子。假设你有一个1分钟的滚动窗口，数据在00:00:30到达。窗口要等到00:01:00才触发。这30秒的等待，就是窗口本身的延迟。再加上计算耗时，总延迟可能到40秒甚至更多。

嗯，这里要注意：窗口延迟和网络延迟、处理延迟不一样。网络延迟是数据在路上的时间，处理延迟是CPU算数据的时间。窗口延迟，是数据在窗口里排队等待被处理的时间。三者叠加，才是用户感知到的端到端延迟。

1.2 延迟对实时系统的影响

延迟高了，系统会出什么问题？我列几个真实场景，你感受一下。

• 风控系统：交易欺诈检测，延迟超过500毫秒，钱可能已经被转走了。我在某支付公司见过一次，窗口配置不合理，延迟飙到3秒，当天损失惨重。
• 监控告警：服务器CPU飙到90%，告警窗口延迟了2分钟才触发。等运维看到告警，服务已经挂了。这种事儿，我经历过不止一次。
• 实时大屏：双十一大屏上的GMV数字，如果延迟超过10秒，老板会直接拍桌子。你想想看，屏幕上显示的数字和实际差了半分钟，那还有什么意义？
• 推荐系统：用户刚点了一个商品，推荐窗口延迟太高，还在推旧内容。用户体验直接崩掉。

为什么会这样？因为实时系统的核心价值就是「快」。延迟一旦失控，实时就变成了「伪实时」，甚至「离线」。我个人的习惯是，任何实时系统上线前，先压测窗口延迟，压到极限再调优。

业务场景	可接受延迟	延迟超标后果
交易风控	< 500ms	资金损失、合规风险
监控告警	< 10s	服务宕机、SLA违约
实时大屏	< 5s	决策失误、信任崩塌
推荐系统	< 1s	用户流失、转化率下降

1.3 延迟的度量指标

度量延迟，不能只靠感觉。我建议用以下几个指标，把延迟量化出来。

1.3.1 端到端延迟

从数据产生到结果输出，全程耗时。这是用户最关心的指标。但要注意，端到端延迟包含网络、序列化、反序列化、窗口等待、计算、输出等多个环节。定位问题时要逐段拆解。

1.3.2 窗口触发延迟

数据进入窗口后，到窗口被触发计算的时间差。这个指标直接反映窗口配置是否合理。比如滚动窗口的触发延迟，理论上等于窗口大小的一半（平均）。但如果数据乱序严重，这个值会大幅增加。

1.3.3 计算处理延迟

窗口触发后，执行聚合、关联、过滤等操作所花费的时间。这个指标主要受数据量和计算复杂度影响。我在项目中遇到过，一个窗口里塞了上亿条数据，计算延迟直接飙到分钟级。

1.3.4 延迟分布统计

只看平均值不够，要看P50、P95、P99、P999。举个例子：

• P50延迟：50%的请求在这个时间内完成
• P99延迟：99%的请求在这个时间内完成
• P999延迟：99.9%的请求在这个时间内完成

我个人的经验是，P99延迟才是系统真实体验的底线。P50再好看，P99一塌糊涂，系统照样不可用。

1.4 窗口计算延迟全景图

下面这张图，把窗口计算延迟的构成、影响和度量指标串起来了。我建议你保存下来，后面每讲一个优化点，都可以回来对照这张图。

从这张图可以清楚看到：延迟不是单一指标，而是一连串环节的累积。每个环节都可能成为瓶颈。后面我们会逐一拆解，给出具体的优化方案。

1.5 本章小结

窗口计算延迟，是实时系统的核心指标。它由窗口等待、计算处理、网络传输等多个环节组成。延迟高了，系统就失去了实时价值。度量时，不要只看平均值，P99和P999才是真正的底线。

嗯，这一章先到这里。记住这张全景图，后面每一章都会用到它。