Flink HA（1） —— zookeeper 在 flink 中的应用

Flink HA

JobManager 高可用（HA）模式加强了 Flink 集群防止 JobManager 故障的能力。 此特性确保 Flink 集群将始终持续执行你提交的作业。

通过将为 jobmanager 提供 leader + standby 的模式，来解决单点故障

官方设计

可选的高可用服务

1. ZooKeeper：每个 Flink 集群部署都可以使用 ZooKeeper HA 服务。它们需要一个运行的 ZooKeeper 复制组（quorum）。
2. Kubernetes：Kubernetes HA 服务只能运行在 Kubernetes 上。

问题：flink yarn 模式是如何实现 jobmanager 的主从多个的？我们在 flink webUI 上似乎没有看到

答案：flink on yarn 模式是不存在 standby 的 jobmanager 的，因为 yarn 提供的资源模式，只允许有一个 master 和 多个 worker，其恢复方式是通过 yarn 对于 master 的拉起来实现 HA 的；

控制参数：

yarn.application-attempts=N

由于，Jobmanager 的 HA 是旧的先挂掉，新的再被拉起，因此需要有一个地方存放用于恢复的信息，这也是 zookeeper 用作高可用服务的原因；

问题：同样能够存储元数据，为什么需要借助于 zookeeper 而不是是直接使用 hdfs

答案：zookeeper 存放数据量更小的元信息、hdfs 存放实际内容；

1. ZooKeeper 更适合做轻量级协调和一致性保证
   1. ZooKeeper 是专门设计用来做分布式协调的服务，具备强一致性保证（顺序写入、原子操作、通知机制等）。
   2. checkpoint 路径是一个小而关键的元信息，写入 ZooKeeper 可以快速完成一致性更新和通知其他组件。
   3. HDFS 主要针对大规模数据存储，不适合做频繁的小数据更新操作（比如频繁写最新 checkpoint 路径）。
2. 低延迟和高可用性
   1. 写 ZooKeeper 节点（znode）是轻量且快速的操作，能保证所有 JobManager 节点实时感知 checkpoint 路径变化。
   2. HDFS 写操作相对较慢，且有可能存在延迟或写入失败等问题，不适合用来做高频次的协调状态更新。
3. 保证 HA 机制的原子性和一致性
   1. ZooKeeper 支持原子操作和顺序节点，能保证在 JobManager 切换时，新 leader 能读取到最新且一致的 checkpoint 路径。
   2. 如果 checkpoint 路径写入 HDFS，可能存在写入时的竞态条件和数据不一致风险。
4. 职责分离，避免把大数据和元数据混合存储
   1. HDFS 专注于存储大量 checkpoint 状态数据（大文件）。
   2. ZooKeeper 专注于存储小规模的元数据和协调信息。

实际问题分析

Flink on yarn 模式下，如果开启了了 yarn 的 attempt 重试，但是没有使用 zookeeper 会产生什么问题呢？ 是否也能够保证 jobmanager 的正常拉起呢？

如下只有 yarn 的 attempt，但是没有 high-availability 的相关配置

yarn.application-attempts = 2

答案： jobmanager 异常时能够拉起，但是无法自动从状态恢复，因为没有 high-availability 去查询可用的 checkpoint 等等，虽然在 hdfs 上有，但是这个路径和查询必须通过 zookeeper 中的元信息指针才能读取到；

产生的问题： 当出现这类情况时（例如 yarn NM 下线导致 jobmanager 异常），当被 yarn 的 attempt 重试拉起时，由于最新 chk 无法找到，flink 任务从零状态启动，会导致计算结果不符合预期，产生严重的质量问题，且这个恢复时间非常快，无法报警通知出来；无感知的情况下产生严重质量问题；

官网其实有所提及，当不开启 HA 时，默认值为 1 也是为了避免自动无状态恢复，造成数据质量问题，切不可在未开启 HA 时，调整该参数 > 1