Flink Runtime 核心机制剖析_flink runtime 代码原理

Flink Runtime 整体架构

Flink Runtime 层的主要架构如下图所示，它展示了一个 Flink 集群的基本结构。整体来说，它采用了标准 master-slave 的结构，master负责管理整个集群中的资源和作业；TaskManager 则是 Slave，负责提供具体的资源并实际执行作业。
​​​​​​

Flink 集群的基本结构

Master 部分包含三个组件：Dispatcher、ResourceManager 和 JobManager。

• Dispatcher：负责接收用户提供的作业，并为作业拉起一个新的 JobManager 组件。
• ResourceManager：负责资源的管理，整个集群中只有一个 ResourceManager。
• JobManager：负责管理作业的执行，每个作业都有各自的 JobManager 组件。

作业执行基本流程：

1. 当用户提交作业时，提交脚本首先启动一个 Client 进程负责作业的编译与提交。
      Clinet 首先将用户的代码编译为一个 JobGraph ，这个过程会进行一个检查或优化等工作。如判断哪些算子可以chain到同一个 Task 中。
      然后，Clinet 将产生的 JobGraph 提交到集群中执行。
      提交时有两种情况：
       1）Session模式：AM 会预先启动，此时 Client 直接与 Dispatcher 建立连接并提交作业即可。
       2）Per-Job模式：AM 不会预先启动，此时 Client 会先向资源管理系统（如yarn）申请资源来启动 AM ，然后再向 AM 中的 Dispatcher 提交作业。
2. 当作业到 Dispatcher 后，Dispatcher 会启动一个 JobManager 组件。
3. JobManager 向 ResourceManager 申请资源来启动作业中具体的任务。
4. Per-Job 模式中 ResourceManager 首先向外部资源管理系统申请资源来启动 TaskManager ，然后 TaskManager 会注册Slot（Slot会执行Task）。
5. ResourceManager 请求到空闲的 Slot 后，就会通知 TaskManager 将“该 Slot 分配给JobManager XX”，然后 TaskManager 进行相应的记录后，向 JobManager 进行注册。
6. JobManager 收到 TaskManager 注册上来的 Slot 后，就可以提交 Task 了。
7. TaskManager 收到 Task 后，会启动一个新的线程来执行 Task。

Flink 支持两种作业执行的模式：

资源管理和作业调度

在 Flink 中，资源是通过 Slot 来表示的，每个 Slot 可以用来执行不同的 Task。任务即 Job 中实际的 Task，它包含了待执行的用户逻辑。
调度的主要目的就是为了给 Task 找到匹配的 Slot。

Flink 中资源管理功能各模块交互的关系

在 ResourceManager 中，有一个子组件叫 SlotManager，它维护了集群中所有TaskManager 上 Slot 的信息和状态，如 slot 当前是否空闲等。

资源交互过程：

1. 当 JobManger 来为特定 Task 申请资源的时候，根据当前是 Per-job 还是 Session 模式，ResourceManager 可能会去申请资源来启动新的 TaskManager。
2. 当 TaskManager 启动之后，它会通过服务发现找到当前活跃的 ResourceManager 并进行注册。
3. 在注册信息中，会包含该 TaskManager 的所有 Slot 信息。
4. ResourceManager 收到注册信息后，其中的 SlotManager 就会记录相应的 Slot 信息。
5. 当 JobManager 为某个 Task 申请资源时，SlotManager 就会从当前空闲的 Slot 中按一定规则选择一个空闲的 Slot 进行分配。
6. 当分配完成后，ResourceManager 会向 TaskManager 发送 RPC 要求将选定的 Slot 分配给特定的 JobManager。
7. TaskManager 如果没有执行过该 JobManager 的 Task 时，它首先需要向 JobManager 建立连接，然后发送提供 Slot 的 RPC 请求。
8. 在 JobManager 中，所有 Task 的请求会缓存到 SlotPool 中。当有 Slot 被提供后，SlotPool 会从缓存的请求中选择相应的 Task 请求并结束相应的请求过程。
9. 当 Task 结束后，无论是正常结束还是异常结束，都会通知 JobManager 相应的结束状态，然后在 TaskManager 端将 Slot 标记为已占用但未执行任务的状态。
10. JobManager 会首先将相应的 Slot 缓存到 SlotPool 中，但不会立即释放。这种方式避免了如果将 Slot 直接还给 ResourceManager，在任务异常结束之后需要重启时，需要立即重新申请 Slot 的问题。通过延时释放，Failover 的 Task 可以尽快调度回原来的 TaskManager，从而加快 Failover 的速度。
11. 当 SlotPool 中缓存的 Slot 超过指定的时间仍未使用时，SlotPool 就会发起释放该 Slot 的过程。SlotPool 首先会通知 TaskManager 来释放该 Slot，然后 TaskManager 通知 ResourceManager 该 Slot 已经被释放，从而最终完成释放的逻辑。

除了正常通信逻辑外，在 ResourceManager 和 TaskManager 之间还存在定时的心跳信息来同步 Slot 的状态。如果长时间未收到对方的心跳，就认为对应的组件已经失效，并进入到 Failover 的流程。

共享Slot

默认情况下，Flink 允许 subtasks 共享 slot，条件是它们都来自同一个 Job 的不同 task 的subtask。结果可能一个 slot 持有该 job 的整个 pipeline。

允许 slot 共享有以下两点好处：

1. Flink 集群需要的任务槽与作业中使用的最高并行度正好相同(前提，保持默认SlotSharingGroup)。
2. 更容易获得更充分的资源利用。

SlotSharingGroup 设置算子的 Slot 共享组。Flink 会将具有相同 Slot 共享组的算子放在同一个 Slot 中，而将没有 Slot 共享组的算子保留在其他 Slot 中，这可用于隔离 Slot 。默认 Slot 共享组的名称是“default”，可以通过调用 算子.slotSharingGroup(“default”) 将算子显示放入该组。

Flink 中两种基本的调度策略
在一个 Flink Job 中是包含多个 Task 的，因此关键的问题是在 Flink 中按什么顺序来调度 Task。
目前 Flink 提供了两种基本的调度逻辑，即 Eager 调度与 Lazy From Source。

• Eager 调度：在作业启动时申请资源将所有的 Task 调度起来。
• Lazy From Source：从 Source 开始，按拓扑顺序来进行调度。当 Source 任务执行完成时，会将输出数据缓存到内存或者写入磁盘中。然后后续任务调度起来会读取上游缓存的输出数据进行自己的计算。

Flink 中两种基本的调度策略

错误恢复

在 Flink 作业的执行过程中，除正常执行的流程外，还有可能由于环境等原因导致各种类型的错误。整体上来说，错误可能分为两大类：Task 执行出现错误或 Flink 集群的 Master 出现错误。由于错误不可避免，为了提高可用性，Flink 需要提供自动错误恢复机制来进行重试。

对于 Task 执行错误，Flink 提供的错误恢复策略：

• Restart-all：直接重启所有的 Task。对于流任务，任务重启可以直接从上次的 Checkpoint 开始继续执行。
• Restart-individual：直接重启出错的任务。只适用于 Task 之间没有数据传输的情况。

对于 Flink 集群的 Master 发生异常：

• 目前 Flink 支持启动多个 Master 作为备份，这些 Master 可以通过 ZK 来进行选主，从而保证某一时刻只有一个 Master 在运行。 为了保证 Master 可以准确维护作业的状态，Flink 目前采用了一种最简单的实现方式，即直接重启整个作业。