2020-09-19

Flink是如何保证高吞吐和低延迟的？

Apache Flink在高吞吐、低延迟等方面都有着非常优秀的表现，是当前分布式实时处理领域一颗冉冉升起的新星，在高吞吐方面的优秀表现，力败称霸多年的Storm，虽然目前还不够成熟，但前景一片大好。那么Flink是如何保证高吞吐和低延迟的呢？

在探讨这个问题之前，我们需要先了解下流处理模型与批处理模型。

流处理标准模型：当一条数据被处理完毕后，先序列化到缓存中，然后立即传输到下一个节点，由下一个节点继续处理。

批处理标准模型：当一条数据被处理完毕后，序列化到缓存中后并不会立即传输给下一节点，如果缓存写满就会持久化到本地磁盘上，当所有的数据都被处理完后，才开始将处理后的数据传输到下一节点

上面两种模式是两种理想的极端情形，上面的流处理标准模型追求最低延迟，牺牲了吞吐量，而批处理标准模型追求极高吞吐量，牺牲了低延迟。Flink以固定的缓存块为单位进行网络数据传输，用户可以通过缓存块超时值指定缓存块的传输时机。如果缓存块的超时值为0，则Flink的数据传输方式类似上面所提到流处理的标准模型，此时系统可以获得最低的处理延迟。如果缓存块的超时值为无限大，则Flink的数据传输方式类似上文所提到批处理的标准模型，此时系统可以获得最高的吞吐量。同时缓存块的超时值也可以设置为0到无限大之间的任意值。缓存块的超时阈值越小，则Flink流处理执行引擎的数据处理延迟越低，但吞吐量也会降低，反之亦然。Flink的执行引擎采用了一种十分灵活的方式，通过调整缓存块的超时阈值，同时支持了这两种模型，用户可根据需求灵活地权衡延迟和吞吐量。可见Flink通过准实时在任务节点间传输数据，来实现低延迟，通过设置缓存来获取高吞吐。

最后再来看下Flink的容错机制，Flink基于分布式快照与可部分重发的数据源实现了容错。用户可自定义对整个Job进行快照的时间间隔，当任务失败时，Flink会将整个Job恢复到最近一次快照，并从数据源重发快照之后的数据。Flink的分布式快照实现的主要思想：按照用户自定义的分布式快照间隔时间，Flink会定时在所有数据源中插入一种特殊的快照标记消息，这些快照标记消息和其他消息一样在DAG中流动，但是不会被用户定义的业务逻辑所处理，每一个快照标记消息都将其所在的数据流分成两部分：本次快照数据和下次快照数据。

快照标记消息沿着DAG流经各个操作符，当操作符处理到快照标记消息时，会对自己的状态进行快照，并存储起来。当一个操作符有多个输入的时候，Flink会将先抵达的快照标记消息及其之后的消息缓存起来，当所有的输入中对应该次快照的快照标记消息全部抵达后，操作符将自己的状态快照并存储，然后处理所有的快照标记消息之后已缓存的消息。操作符对自己的状态快照并存储可以是异步与增量的操作，因此并不会阻塞消息的处理。

当所有的Data Sink（终点操作符）都收到快照标记信息并对自己的状态进行快照和存储后，整个分布式快照也就完成了，同时通知数据源释放该快照标记消息之前的所有消息。若之后发生节点崩溃等异常情况时，只需要恢复之前存储的分布式快照状态，并从数据源重发该快照以后的消息就可以了。

Exactly-Once是流处理系统需要支持的一个非常重要的特性，它保证每一条消息只被流处理系统处理一次，许多流处理任务的业务逻辑都依赖于Exactly-Once特性。相对于At-Least-Once和At-Most-Once, Exactly-Once特性对流处理系统的要求更为严格，实现也更加困难。Flink基于分布式快照实现了Exactly-Once特性。

相对于其他流处理系统的容错方案，Flink基于分布式快照的方案在功能和性能方面都具有很多优点，包括：
低延迟：由于操作符状态的存储可以异步，所以进行快照的过程基本上不会阻塞消息的处理，因此不会对消息延迟产生负面影响。
高吞吐量：当操作符状态较少时，对吞吐量基本没有影响。当操作符状态较多时，相对于其他的容错机制，分布式快照的时间间隔是用户自定义的，所以用户可以权衡错误恢复时间和吞吐量要求来调整分布式快照的时间间隔。
与业务逻辑的隔离：Flink的分布式快照机制与用户的业务逻辑是完全隔离的，用户的业务逻辑不会依赖或是对分布式快照产生任何影响。
错误恢复代价：分布式快照的时间间隔越短，错误恢复的时间越少，与吞吐量负相关。

可见Flink的容错机制也在一定程度上确保了系统的低延迟、高吞吐等特性。