FLIP-6 Flink runtime设计文档摘要（二）

这篇主要讲信息流和容错的设计

组件设计细节

资源分配流程

slot-allocation-with-new-taskmanager.png

• 4,6丢失则消息4重发，AllocationID用来标志资源请求保证重发的时候RM不会重复申请资源。如果在重试之前，之前分配的slot已经被释放了，那么可能会重新启动一个container（之前为了申请slot启动了一个TM，分配了一个slot但是没用，所以自动释放了，RM认为没有可用的slot了，又启动了一个TM？？？）
• 10丢失，则可以依靠TM的自动重新连接机制。ResourceID可以用来区分重复注册
• 12丢失，则超时重发。在后面注册环节注册时提供了（AllocationID，ResourceID）会因为AllocationID冲突导致注册失败（忽略注册信息）
• 13丢失，可以依靠心跳信息来保证消息
• 14丢失，依靠TM自动重新连接，依靠（AllocationID，ResourceID）

失败处理

TaskManager 挂了

• ResourceManager
  • 检测方式，通过心跳超时
  • 在yarn和mesos下，可以通过集群管理器额外获得通知
  • 从 live tm 列表中清除TM
  • 如果有JM分配了这个TM的slot，则向这些JM发送TM挂了的信息
  • 启动新的container替换
• JM
  • 检测方式，心跳超时
  • 可能会提前收到消息（来自RM）
  • 从slot pool中移除 来自这个TM的slot
  • 标记在那个slot中运行的task挂了，启动task恢复逻辑
  • 如果资源不够了，job降级？
• 失去的数据
  • 运行的operator状态，不过可以通过checkpoint恢复
• 恢复动作
  • 重启的TM会查找RM并重新注册slot信息

RM挂了

• TaskManager

  • 检测方式：心跳超时
  • HA：在RM失去leader身份时会得到通知
  • 进入重新注册RM的逻辑，不过不需要取消任务
  • 一旦注册成功，向RM发送当前的slot都分配给了那些job。当前可用的slot有多少

• JobManager

  • 检测方式：心跳超时
  • HA：在RM失去Leader身份时会得到通知
  • JM等待RM恢复（通过leader-election service会得到通知），重新发送在pending request列表中的信息（只有资源申请收到了影响）

• 失去的数据

  • 当前运行的container：从cluster manager中获得
  • 可用的slot：从TM注册获得
  • slot的分配情况：从TM注册获得（slot分给了哪个job）
  • 延迟的slot 分配申请：JM会重新申请资源，发送资源请求

可能会发生RM启动了一个container，之后RM挂了，恢复之后又启动了一个container。

第二个container会因为没有使用被自动释放（在一段时间之内）

JM挂了

• TaskManager
  • 检测方式：心跳超时
  • HA：
  • TM触发 master挂了的动作（当前是释放所有task）
  • TM尝试重新注册JM（在一段时间之内）
  • 如果JM没活过来则已经分配的slot会被报告给RM可以被分配给其他JM
• ResourceManager
  • 检测方式：心跳超时
  • HA：
  • 可能会通知TM说JM挂了，之外没啥动作了
• 失去的数据
  • JobGraph，库，可以从持久存储中获得（HDFS）
  • 完成的checkpoint元数据信息，从HA中获得
  • 任务的执行状态，任务会从上个checkpoint开始
  • 已经注册的TM，TM会重新注册相关信息
• 恢复动作
  • 获得leader状态
  • 注册RM，（为了获得TM挂了的信息）
  • 触发job从上次完成的checkpoint恢复

JM和RM挂了

• TM正常执行JM挂了的逻辑
• TM会尝试提供给新的JMslot
• TM停留在RM注册循环中

TM和RM挂了

• JM不能从RM获取TM挂了的信息，但是可以通过心跳超时检测到
• 资源申请全部超时（或者取消），在RM上线的时候会尝试重新启动
• JM可能会job降级