为什么是Flink？

本篇讲讲Flink，主要有

• 基于事件时间的消息处理机制
• flink的容错机制

都说flink很火，那么它到底有什么过人之处呢。看了《Flink基础教程》，总结一下。

1. flink性能好，市面上的测试结果显示，流处理方面flink较storm有更好的表现，甚至是在某些批处理上的性能测试中，flink竟然胜出了spark。
2. flink能满足基于事件时间分析的需求，市面上应该只此一家了。
3. flink的容错处理机制，能保证exact once处理。

好了，介绍完特性，来逐条讲讲，首先看第二点：

基于事件时间的消息处理机制

将这个机制之前，首先了解下flink的3种时间概念

1. 事件时间：消息在设备中的产生时间
2. 摄入时间：消息进入flink的时间

3. 处理时间：消息被flink中特定操作处理的时间
   借用官网的图来理解：

   
   image.png

那好，基于事件时间处理到底什么意思。比如我要统计在2019/2/20 9:10-9:15产生的消息总数，那么消息发生到传入flink肯定有延时，flink中可以基于窗口函数来实现某一时间段流数据的处理，那么问题来了，我这个窗口函数什么时候结束？

有些人肯定就会想，用系统时间不就行了，当服务器的时间超过了9:15，这个窗口函数就可以触发了呀，处理这个时间段的数据。基于处理时间的消息处理就是这么做的（这也是flink默认的处理机制）。但是消息到底flink是有网络延迟的，可能我9:14产生的数据，9:16才到达flink，如果按照上诉策略，这个窗口函数已经触发了，下个窗口是9:15到9:20，也不会处理这个消息，所以这个消息就被丢弃了。那可如何是好？

于是，flink引入了一个叫水印（watermark）的概念。水印的作用就是决定你这个窗口函数什么时候触发。

水印

水印说白了就是每个消息的时间戳，但是一个window操作只有一个水印，这说明水印不断再更新，这个消息的时间戳和当前窗口函数的水印比较选最大值（最迟的）如果后来的消息小于它，就是乱序的 。 水印更新的时机有两种策略

1. 周期性，默认200ms
2. 基于事件触发

在不考虑容忍延迟的时间，如果系统时间大于水印，窗口函数就会触发。
如果考虑容忍延迟时间，比如：

stream.allowedLateness(Time.seconds(2))

那么，这个窗口会在水印时间比原来的设定触发的时间再多两秒时触发，为了等待乱序的消息，牺牲点时间。

关于水印的详解，还可以参考https://juejin.im/post/5bf95810e51d452d705fef33，里面有具体的例子。

前面提到很多次窗口，简单介绍下窗口

窗口

窗口就是，对某一种范围内数据触发一次函数处理，这个范围可以是时间（某一时间段消息计数），也可以是数量（5个消息的总长度）。

时间窗口

最简单有用的，支持滚动和滑动。

1. 滚动:两个窗口不重叠

stream.timeWindow(Time.minute(1))

2. 滑动：两个窗口会重叠，下述代码表示2秒的时间窗口，每隔一秒滚动一次。

stream.timeWindow(Time.minute(2)，Time.minute(1))

计数窗口

和上面类似，也有滚动，滑动

stream.countWindow(4，2)

会话窗口

stream.window(SessionWindows.withGap(Time.minute(4)))

触发器

窗口的触发都是有触发器完成的，例如上面基于事件时间的窗口，触发条件就是根据水印判断。用户也可以自定义触发器

基于事件时间的消息处理机制还是很好理解的，但是市面上好像还没有类似的流处理引擎，大多是基于处理时间的。

flink的容错机制

分布式系统头疼的一件事便是一致性问题。说白了，就是系统故障修复后能还原到故障前的什么程度。

在流处理中，一致性分为3个级别：

1. at-most-once（可能少读）
2. at-least-once（可能重复读）
3. exactly-once （正好）

支持at-least-once的有Storm Trident和spark streaming，但是两者在性能上的开销太大了。它们通过微批处理来保证，就是说，无法将消息单条处理，而是等待一批完全处理完，下一批再处理，可想而知，增加了延时。而flink牛逼的地方在于它不仅保证了exactly-once而且效率很高。 那它如何保证exactly-once的呢？

checkpoint

熟悉spark的同学大概都知道这个概念，spark可以将中间rdd的计算结果保存到磁盘中，下次通过该rdd的算子，就不用从头开始计算，直接从这个checkpoint开始计算。

flink消息中穿插了checkpoint消息，当遇到该消息时，每个节点会将当前消息偏移量（以kafka为例），该操作中间计算结果落盘。等到恢复时，直接从该checkpoint恢复。那么，还是会可能出现checkpoint点到故障时这段时间的消息会被读两次啊，如果是写入到数据库，那可能就会写两次了。那是如何exactly-once 的啊？这就涉及到端到端的一致性问题了，类似数据库中的事务。解决方法有两种：

1. 读已提交，flink sink（落盘）时维护一个缓冲区，等到checkpoint时，再将缓冲区数据落盘（原子型操作）
2. 读未提交，以流式方式落盘，可能会重复落盘。当故障时，需要回滚。

---

本篇只是分析了flink两个方面，后续深入了解后再更新其他特性。
参考资料 ：

1. 《flink基础教程》
2. https://juejin.im/post/5bf95810e51d452d705fef33