1.Flink如何保证Exactly-Once

• 使用checkpoint检查点，其实就是 所有任务的状态，在某个时间点的一份快照；这个时间点，应该是所有任务都恰好处理完一个相同 的输入数据的时候。
• checkpoint的步骤：flink应用在启动的时候，flink的JobManager创建CheckpointCoordinatorCheckpointCoordinator(检查点协调器) 周期性的向该流应用的所有source算子发送 barrier(屏障)。当某个source算子收到一个barrier时，便暂停数据处理过程，然后将自己的当前状态制作成快照，并保存到指定的持久化存储（hdfs）中，最后向CheckpointCoordinator报告自己快照制作情况，同时向自身所有下游算子广播该barrier，恢复数据处理下游算子收到barrier之后，会暂停自己的数据处理过程，然后将自身的相关状态制作成快照，并保存到指定的持久化存储中，最后向CheckpointCoordinator报告自身快照情况，同时向自身所有下游算子广播该barrier，恢复数据处理。每个算子按照 上面这个操作 不断制作快照并向下游广播，直到最后barrier传递到sink算子，快照制作完成。当CheckpointCoordinator收到所有算子的报告之后，认为该周期的快照制作成功; 否则，如果在规定的时间内没有收到所有算子的报告，则认为本周期快照制作失败。

2.Flink的双流Join分为哪几类

• 分为window join和interval join两种window join：将两条实时流中元素分配到同一个时间窗口中完成Joininterval join：根据右流相对左流偏移的时间区间(interval)作为关联窗口，在偏移区间窗口中完成join操作

3.Flink是如何处理反压的

• 反压就是指下游数据的处理速度跟不上上游数据的生产速度，Flink处理反压的流程如下：每个TaskManager维护共享Network BufferPool（Task共享内存池），初始化时向Off-heap Memory中申请内存。每个Task创建自身的Local BufferPool（Task本地内存池），并和Network BufferPool交换内存。上游Record Writer向 Local BufferPool申请buffer（内存）写数据。如果Local BufferPool没有足够内存则向Network BufferPool申请，使用完之后将申请的内存返回Pool。Netty Buffer拷贝buffer并经过Socket Buffer发送到网络，后续下游端按照相似机制处理。当下游申请buffer失败时，表示当前节点内存不够，则逐层发送反压信号给上游，上游慢慢停止数据发送，直到下游再次恢复。

4.Flink的watermark如何理解

• 简单来说，它就是一种特殊的时间戳，作用就是为了让事件时间慢一点，等迟到的数据都到了，才触发窗口计算。我举个例子说一下为什么会出现watermark？
• 比如现在开了一个5秒的窗口，但是2秒的数据在5秒数据之后到来，那么5秒的数据来了，是否要关闭窗口呢？可想而知，关了的话，2秒的数据就丢失了，如果不关的话，我们应该等多久呢？所以需要有一个机制来保证一个特定的时间后，关闭窗口，这个机制就是watermark

5.Flink的窗口机制分为哪几类

• 分为Time Window、Count Window和Session Window三种时间窗口根据时间对数据进行划分，分为Tumbling Time Window和Sliding Time Window，其中滚动时间窗口会将数据流切分成不重叠的窗口，每一个事件只能属于一个窗口；滚动时间窗口中的一条数据可以对应多个窗口计数窗口根据元素个数对数据进行划分，分为Tumbling Count Window和Sliding Count Window会话窗口根据会话来对数据进行划分，简单来说，就是数据来了之后就开启一个会话窗口，如果接下来还有数据陆续到来，那么就一直保持会话；如果一段时间一直没收到数据，那就认为会话超时失效，窗口自动关闭

6.Flink是如何处理迟到数据的

• watermark设置延迟时间
• window的allowedLateness方法，可以设置窗口允许处理迟到数据的时间
• window的sideOutputLateData方法，可以将迟到的数据写入侧输出流