flink组件扫盲

https://blog.csdn.net/wypblog/article/details/103900577

flink怎么保持数据一致性

1. flink在快照过程中，一个节点挂了怎么办

https://zhuanlan.zhihu.com/p/348559815
在 Flink 中需要端到端精准一次处理的位置有三个：

Source 端：数据从上一阶段进入到 Flink 时，需要保证消息精准一次消费。可重设数据的读取位置，当发生故障时重置偏移量到故障之前的位置。
Flink 内部端：这个我们已经了解，利用 Checkpoint 机制，把状态存盘，发生故障的时候可以恢复，保证内部的状态一致性。checkpoint，发生故障时能够恢复各个环节的数据。
Sink 端：将处理完的数据发送到下一阶段时，需要保证数据能够准确无误发送到下一阶段。从故障恢复时，数据不会重复写入外部系统，幂等写入，事务写入。

在 Flink 1.4 版本之前，精准一次处理只限于 Flink 应用内，也就是所有的 Operator 完全由 Flink 状态保存并管理的才能实现精确一次处理。但 Flink 处理完数据后大多需要将结果发送到外部系统，比如 Sink 到 Kafka 中，这个过程中 Flink 并不保证精准一次处理。
在 Flink 1.4 版本正式引入了一个里程碑式的功能：两阶段提交 Sink，即 TwoPhaseCommitSinkFunction 函数。该 SinkFunction 提取并封装了两阶段提交协议中的公共逻辑，自此 Flink 搭配特定 Source 和 Sink（如 Kafka 0.11 版）实现精确一次处理语义(英文简称：EOS，即 Exactly-Once Semantics)。

端到端精准一次处理语义（EOS）
以下内容适用于 Flink 1.4 及之后版本
对于 Source 端：Source 端的精准一次处理比较简单，毕竟数据是落到 Flink 中，所以 Flink 只需要保存消费数据的偏移量即可， 如消费 Kafka 中的数据，Flink 将 Kafka Consumer 作为 Source，可以将偏移量保存下来，如果后续任务出现了故障，恢复的时候可以由连接器重置偏移量，重新消费数据，保证一致性。

• kafka的offset放在存到broker服务器上，一旦这个消费者启动，这个消费者组名和它要消费的那个topic的offset信息就会被记录在broker服务器上
  在新版 Kafka 以及之后的版本，Kafka 消费的offset都会默认存放在 Kafka 集群中的一个叫 __consumer_offsets 的topic中。
• 利用 Kafka 自身的 Topic，以消费的Group，Topic，以及Partition做为组合 Key。所有的消费offset都提交写入到上述的Topic中。因为这部分消息是非常重要，以至于是不能容忍丢数据的，所以消息的 acking 级别设置为了 -1，生产者等到所有的 ISR 都收到消息后才会得到 ack（数据安全性极好，当然，其速度会有所影响）。所以 Kafka 又在内存中维护了一个关于 Group，Topic 和 Partition 的三元组来维护最新的 offset 信息，消费者获取最新的offset的时候会直接从内存中获取。
• ack：min.insync.replicas=n 配置参数表示 当满足了n个副本的消息确认（n默认为1，最好大于因为leader 也在isr 列表中），才认为这条消息是发送成功的；min.insync.replicas 参数只有配合request.required.acks =-1 时才能达到最大的可靠性
  request.required.acks 的参数说明：
  acks为0：这意味着producer发送数据后，不会等待broker确认，直接发送下一条数据，性能最快
  acks为1：为1意味着producer发送数据后，需要等待leader副本确认接收后，才会发送下一条数据，性能中等
  acks为-1：这个代表的是all，意味着发送的消息写入所有的ISR集合中的副本（注意不是全部副本）后，才会发送下一条数据，性能最慢，但可靠性最强

Flink 内部端：Flink 使用了一种轻量级快照机制 — 检查点（checkpoint） 来保证 exactly-once 语义；有状态应用的一致性检查点，就是所有任务的装在，在某个时间点的一份快照，而这个时间点，应该是所有任务都恰好处理完一个相同的输入数据的时候，应用状态的一致检查点，就是 flink 故障恢复机制的核心

对于 Sink 端：Sink 端是最复杂的，因为数据是落地到其他系统上的，数据一旦离开 Flink 之后，Flink 就监控不到这些数据了，所以精准一次处理语义必须也要应用于 Flink 写入数据的外部系统，故这些外部系统必须提供一种手段允许提交或回滚这些写入操作，同时还要保证与 Flink Checkpoint 能够协调使用（Kafka 0.11 版本已经实现精确一次处理语义）。

我们以 Flink 与 Kafka 组合为例，Flink 从 Kafka 中读数据，处理完的数据在写入 Kafka 中。
为什么以Kafka为例，第一个原因是目前大多数的 Flink 系统读写数据都是与 Kafka 系统进行的。第二个原因，也是最重要的原因 Kafka 0.11 版本正式发布了对于事务的支持，这是与Kafka交互的Flink应用要实现端到端精准一次语义的必要条件。

当然，Flink 支持这种精准一次处理语义并不只是限于与 Kafka 的结合，可以使用任何 Source/Sink，只要它们提供了必要的协调机制。
Flink 与 Kafka 组合


快照具体的算法：先进先出的单向无环图
https://zhuanlan.zhihu.com/p/43536305

所有的通信channel需要是先进先出(FIFO)按顺序的
中心coordinator：需要有一个中心coordinator来不断广播持续增长的stage barrier到所有的src数据流里。(比如先给所有src发1，然后5秒后发2，10秒发3… 如此增长)
数据源src，当数据源收到第n个barrier的时候:
-保存状态，保证当需要replay从任意n开始的消息时，可以replay在自己收到barrier-n之后的所有消息。
-广播barrier给下游。
中间处理节点或最终叶子节点：假设一个中间处理节点或最终叶子节点需要m个input流，当在某个input流收到barrier-n的时候，
-block这个input流保证不再收取和处理。
-当收到所有m个input的barrier-n的时候，
–Pi-LocalSnapshot-n: 保存本地状态(take local snapshot n), 保证可以从这个状态恢复(比如存到云端, 在另外x台机器做replica)，假设我们每个logic processor都有一个id为Pi，那么每个logic processor的在收到所有inputs的barrier-n之后所保存的本地状态快照则设为Pi-LocalSnapshot-n
–向自己的下游广播barrier-n （如果是叶子节点没有下游，那么不需要广播）
CompleteGlobalSnapshot-n: 当所有的节点(源，中间处理，叶子节点)都处理完barrier-n且完成取快照(take snapshot)的任务之后，我们说我们有了一个完整的全局快照。这意味着我们的deterministic的进度，进步到了barrier-n

flink和kafka的配合

https://blog.csdn.net/sghuu/article/details/103705177
https://www.hnbian.cn/posts/6adf75db.html

kafka的事务：https://zhuanlan.zhihu.com/p/120796378