实时大数据计算中，Flink的滑动窗口，乱序，允许消息迟到机制

前几天写了《实时大数据计算中，Spark的滑动窗口和允许消息迟到机制》，这几天一时兴起，对Flink的实时计算机制进行记录。

乱序和迟到的定义

Flink的实时计算控制好像比Spark多出了一个，就是关于乱序数据的处理，在Flink的定义中，乱序与迟到由相同点和不同点，首先相同点在于，它们都指代，处于时间窗口之外的数据，其中乱序范围称为乱序界，迟到范围称为迟到界，每个窗口都有自己的乱序界和迟到界，以窗口W1为例，假设窗口范围是 [00:00,00:05) 如果允许乱序时间为10s，迟到时间为30s。

         窗口                    ──  allowedLateness=30s  ──│                     │                           │▼                     ▼                           ▼
00:00   00:05 ←  乱序界10s  →  00:15  ←    迟到界30s     →  00:35▲                     ▲                           ▲│                     │                           │乱序阶段             允许迟到阶段                  彻底关闭（等10秒）            （再等30秒）                  （丢弃）

窗口计算机制，乱序消息，迟到消息

在Spark Streaming中，窗口时间一到达，就会触发一次窗口内计算，后续迟到的数据算一次更新操作。在Flink中，窗口的计算是由消息的事件时间来决定的（当策略是noWatermarks时，就按照窗口来计算）。如果一段连续的消息，它们的事件时间是

00:01  00:02

这些时间的最大值是00:02，在窗口范围内，达不到触发窗口计算的要求，此时数据会积累起来，只是不会去计算。需要注意的是，这些消息到达Flink的时间（处理时间）不是按顺序的，事件时间较大的有可能先到，但是没关系，处理时间不参与窗口计算触发机制。
另一种情况，假设一段连续的消息中，包含一些消息的事件时间在窗口范围外，但在乱序界的范围内，即

00:01  00:02  00:07  00:04

此时最大事件时间为00:07，超出了窗口区间的右端点，后面出现的窗口范围内的消息都可以叫做乱序消息。此时依然不会触发窗口计算。事件时间00:04的消息算在W1 - [00:00,00:05)范围内，00:07，00:09，00:08这三条消息属于W2 - [00:05,00:10)范围内。
如果此时，连续消息中最新出现了一条超出乱序界范围的消息，即

00:01  00:02  00:03  00:07  00:04  00:09  00:08  00:15

此时W1的计算触发，数据 00:01，00:02，00:03，00:04，会按照预设的窗口进行计算。
进一步可知，触发窗口计算的代码逻辑是

int watermask = MaxEventTime - 10s;
if(watermask >= window_right){triggerWindow();
}

window_right是窗口区间的右端，一旦计算，窗口就会关闭。
进一步，如果后续还继续出现需要在W1中计算的数据，即

00:01  00:02  00:07  00:04  00:09  00:08  00:15  00:03

这个时间事件为00:03的消息被称为迟到消息，这个消息在30s的迟到判定条件下会纳入W1窗口内计算，只是这次计算算作是更新操作。迟到更新是对每条迟到数据都会进行判定，允许每条消息都比自身事件时间迟到30s，判断逻辑如下

Watermark >= window_end 且 eventTime < Watermark 且 eventTime + allowedLateness >= Watermark

这三个判断条件分别代表窗口已关闭，该数据属于迟到数据，仍在宽限期内。
前两个比较好理解，但是仍在宽限期内可能不大好理解。但可能这样解释会清晰些，就是
目前的Watermark还没有更新到我迟到30s之后的程度，所以我依然是可以回去W1的。

代码实现

未完待续