字节跳动 Flink 单点恢复功能实践

根据这些想法我们思考得出几个比较关键点在于：

• 如何让上下游感知 Task Failed ?

• 如何清空下游不完整的数据 ?

• Failover 完成后如何与上下游重新建立连接 ?

基于以上考虑我们决定基于已有的 Network 层线程模型，修改上下游对于 Task Failed 后的处理逻辑，让非故障的 Tasks 短时间内完成对失败 Task 的感知操作，从而使得作业持续稳定地输出。

当前架构

---

注：我们的实现基于 Flink-1.9，1.11 后的网络模型加入了 Unaligned Checkpoint 的特性，可能会有所变化。

我们先将 Flink 的上下游 Task 通信模型简单抽象一下：

Figure. 上下游通信模型

上下游 Task 感知彼此状态的逻辑，分三种情况考虑：

• Task 因为逻辑错误或 OOM 等原因 Fail，Task 自身会主动释放 network resources，给上游发送 channel close 信息，给下游发送 Exception。

• TaskManager 进程被 Yarn Kill，TCP 连接会被操作系统正常关闭，上游 Netty Server 和下游 Netty Client 可以感知到连接状态变化。

• 机器断电宕机，这个情况下操作系统不会正确关闭 TCP 连接，所以 Netty 的 Server 和 Client 可能互相感知不到，这个时候我们在 deploy 新的 Task 后需要做一些强制更新的处理。

可以看到，在大部分情况下，Task 是可以直接感知到上下游 Task 的状态变化。了解了基础的通信模型之后，我们可以按照之前的解决思路继续深入一下，分别在上游发送端和下游接收端可以做什么样改进来实现单点恢复。

优化方案

---

根据我们的解决思路，我们来绘制一下单个 Task 挂了之后，整个 Job 的通信流程：

Figure. 单点恢复流程

Map(1) 失败之后：

1. 将 Map(1) 失败的信息通知 Source(1) 、Sink(1) 和 JobManager。

2. JobManager 开始申请新的资源准备 Failover，同时上游 Source(1) 和下游 Sink(1) 切断和 Map(1) 的数据通道，但是 Source(1) 和 Sink(1) 和其他 Task 的数据传输仍正常进行。

3. Map(1)’ 被成功调度，和上游建立连接，JobManager 通知 Sink(1) 和 Map(1)’ 建立连接，数据传输通道被恢复。

从这个流程，我们可以将优化分为三个模块，分别为上游发送端、下游接收端和 JobManager。

上游发送端的优化

我们再细化一下上游发送端的相关细节，

Figure. 上游数据发送流程

(1) Netty Server 收到 Client 发送的 Partition Request 后，在对应的 Subpartition 注册读取数据的 SubpartitionView 和 Reader。

(2) RecordWriter 发送数据到不同的 Subpartitions，每个 Subpartition 内部维护一个 buffer 队列，并将读取数据的 Reader 放入到 Readers Queue 中。（Task 线程）

(3) Netty 线程读取 Readers Queue，取出对应的 Reader 并读取对应 Subpartition 中的 buffer 数据，发送给下游。（Netty 线程）

我们的期望是上游发送端在感知到下游 Task 失败之后，直接将发送到对应 Task 的数据丢弃。那么我们的改动逻辑，在这个示意图中，就是 Subpartition 通过 Netty Server 收到下游 Task Fail 的消息后，将自己设置为 Unavailable，然后 RecordWriter 在发送数据到指定 Subpartition 时，判断是否可用，如果不可用则直接将数据丢弃。而当 Task Failover 完成后重新与上游建立连接后，再将该 Subpartition 置为 Available，则数据可以重新被消费。

发送端的改动比较简单，得益于 Flink 内部对 Subpartition 的逻辑做了很好的抽象，并且可以很容易的通过参数来切换 Subpartition 初始化的类型，我们在这里参考 PipelinedSubpartition 的实现，根据上述的逻辑，实现了我们自己的 Subpartition 和对应的 View。

下游接收端的优化

同样，我们来细化一下下游接收端的细节：

Figure. 下游数据接收流程

仔细来看，其实和上游的线程模型颇有类似之处：

(1) InputGate 初始化所有的 Channel 并通过 Netty Client 和上游 Server 建立连接。

(2) InputChannel 接收到数据后，缓存到 buffer 队列中并将自己的引用放入到 Channels Queue 里。（Netty 线程）

(3) InputGate 通过 InputProcessor 的调用，从 Queue 里拉取 Channel 并读取 Channel 中缓存的 buffer 数据，如果 buffer 不完整（比如只有半条 record），那么则会将不完整的 buffer 暂存到 InputProcessor 中。（Task 线程）

这里我们期望下游接收端感知到上游 Task 失败之后，能将对应 InputChannel 的接收到的不完整的 buffer 直接清除。不完整的 buffer 存储在 InputProcessor 中，那么我们如何让 InputProcessor 知道哪个 Channel 出现了问题？

简单的方案是说，我们在 InputChannel 中直接调用 InputGate 或者 InputProcessor，做 buffer 清空的操作，但是这样引入一个问题，由于 InputChannel 收到 Error 是在 Netty 线程，而 InputProcessor 的操作是在 Task 线程，这样跨线程的调用打破了已有的线程模型，必然会引入锁和调用时间的不确定性，增加架构设计的复杂度，并且因为 InputProcessor 会对每一条 record 都有调用，稍有不慎就会带来性能的下降。

我们沿用已有的线程模型，Client 感知到上游 Task 失败的消息之后告知对应的 Channel，Channel 向自己维护的 receivedBuffers 的末尾插入一个 UnavailableEvent，并等待 InputProcessor 拉取并清空对应 Channel 的 buffer 数据。示意图如下所示，红色的模块是我们新增的部分：

Figure. 下游改动示意图

JobManager 重启策略的优化

JobManager 重启策略可以参考社区已有的 RestartIndividualStrategy，比较重要的区别是，在重新 deploy 这个失败的 Task 后，我们需要通过 ExecutionGraph 中的拓扑信息，找到该 Task 的下游 Tasks，并通过 Rpc 调用让下游 Tasks 和这个新的上游 Tasks 重新建立连接。

这里实现有一个难点是如果 JobManager 去 update 下游的 Channel 信息时，旧的 Channel 对应的 buffer 数据还没有被清除怎么办？我们这里通过新增 CachedChannelProvider 来处理这一逻辑：

Figure. 更新 Partition

如图所示，以 Channel - 1 为例，如果 JobManager 更新 Channel 的 Rpc 请求到来时 Channel 处于不可用状态，那么我们直接利用 Rpc 请求中携带的 Channel 信息来重新初始化 Channel。以 Channel - 3 为例，如果 Rpc 请求到来时 Channel 仍然可用，那么我们将 Channel 信息暂时缓存起来，等 Channel - 3 中所有数据消费完毕后，通知 CachedChannelProvider，然后再通过 CachedChannelProvider 去更新 Channel。

这里还需要特别提到一点，在字节跳动内部我们实现了预留 TaskManager 的功能，当 Task 出现 Failover 时，能够直接使用 TaskManager 的资源，大大节约了 Failover 过程数据丢失的损耗。

实现中的关键点

整个解决的思路其实是比较清晰的，相信大家也比较容易理解，但是在实现中仍然有很多需要注意的地方，举例如下：

• 上面提到 JobManager 发送的 Rpc 请求如果过早，那么会暂时缓存下来等待 Channel 数据消费完成。而此时作业的状态是未知的，可能一直处于僵死的状态（比如卡在了网络 IO 或者 磁盘 IO 上），那么 Channel 中的 Unavailable Event 就无法被 InputProcessor 消费。这个时候我们通过设置一个定时器来做兜底策略，如果没有在定时器设置的时间内完成 Channel 的重新初始化，那么该 Task 就会自动下线，走单点恢复的 Failover 流程。

• 网络层作为 Flink 内线程模型最复杂的一个模块，我们为了减少改动的复杂度和改动的风险，在设计上没有新增或修改 Netty 线程和 Task 线程之间通信的模型，而是借助于已有的线程模型来实现单点恢复的功能。但在实现过程中因为给 Subpartition 和 Channel 增加了类似 isAvailable 的状态位，所以在这些状态的修改上需要特别注意线程可见性的处理，避免多线程读取状态不一致的情况发生。

收益

最后

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长，自己不成体系的自学效果低效漫长且无助。

因此我收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点！不论你是刚入门Android开发的新手，还是希望在技术上不断提升的资深开发者，这些资料都将为你打开新的学习之门

如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！
础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点！不论你是刚入门Android开发的新手，还是希望在技术上不断提升的资深开发者，这些资料都将为你打开新的学习之门**

如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！