关于数据库:宕机了DolphinScheduler-高可用和-Failover-机制关键时刻保命

9次阅读

共计 2205 个字符，预计需要花费 6 分钟才能阅读完成。

高可用性是 Apache DolphinScheduler 的个性之一。它通过冗余来防止单点问题，所有组件人造反对横向扩容；但仅仅保障了冗余还不够，当零碎中有节点宕机时，还须要有故障转移机制可能主动将宕机节点正在解决的工作转移到新节点上执行，从而实现高可用。

Apache DolphinScheduler 是一个分布式易扩大的工作流编排调度零碎。其外围架构次要由 3 局部组成：APIServer, Master, Worker。

其中 API-Server 负责接管所有的用户操作申请，Master 负责工作流的编排和调度，Worker 负责工作流中工作的执行。整个零碎通过注册中信做服务发现，通过数据库长久化元数据。

一个工作流执行的生命周期如下：

在 API-Server 中创立，并将元数据长久化到 DB 中。
通过手动点击或定时执行生成一个触发工作流执行的 Command 写入 DB。
Master 生产 DB 中的 Command，开始执行工作流，并将工作流中的工作分发给 Worker 执行。
当整个工作流执行完结之后，Master 完结工作流的执行。

分布式系统中必须要思考的因素是零碎整体的高可用（HA）。高可用指的是零碎整体可能对外提供服务的工夫占比很高，零碎因为故障而无奈提供服务的工夫占比很短。

为了保证系统的高可用，架构的一个设计准则是通过冗余来避免出现单点问题。单点问题是指零碎中某一工作组件只有单个实例，如果该实例呈现了故障，那么会导致系统整体不可用。

Apache DolphinScheduler 也是通过冗余来防止单点问题，在 DolphinScheduler 中，所有组件人造就反对横向扩容。

对于 API-Server 来说，因为 API-Server 是一个无状态服务，因而 API-Server 能够很容易的通过部署多台来保障高可用。在部署多台 API-Server 之后，只须要将他们注册在同一网关，即可一起对外提供服务。

Master 作为 DolphinScheduler 中解决工作流的外围组件，其可用性间接关系到整个零碎的稳定性。

因为 Master 并不像 API-Server 一样只是被动的接管外界的申请，Master 会被动的生产数据库中的工作流，而一个工作流在某一时刻只能被一个 Master 解决，因而 Master 在横向扩容的时候须要思考的问题更多。

一种比较简单的计划是采纳 active-standby 的形式，即部署多台 Master 服务，然而只有一台处于 active 状态，对外工作，其余 Master 服务都处于 standby 状态，只有等 active 的 Master 宕机，standby 状态的 Master 会从新选举出一台新的 active Master 对外工作。

这种计划实现起来简略，同时能够很好的解决 Master 单点问题，然而这种 active-standby 的架构同一时刻只能有一台 Master 进行工作，对于 DolphinScheduler 来说，因为 Master 须要解决工作流的调度，因而这会导致整个集群的工作流解决吞吐量上不去。

在 DolphinScheduler 中采纳分片的形式对工作流元数据进行了预划分，具体来说对工作流产生的 command 依据 id 进行分片，将 command 平均的扩散到所有的 Master，这样来达到所有 Master 都能够同时工作，并且不会相互影响。

Master 通过注册核心来感知集中其余 Master 的节点信息，因为当节点高低线的时候，Master 的元数据变更告诉到所有 Master 服务工夫会不统一，因而通过数据库事务做了进一步的保障，保障同一个 Command 只会被解决一次。

Worker 作为 DolphinScheduler 中工作执行组件，其扩大比拟容易，这是因为在设计上，Worker 次要是被动的接管 Master 散发的工作，他不会被动去数据库中拉取工作。因而 Woker 只须要在横向扩容之后注册到注册核心即可，Master 会通过注册核心感知到 Worker 的元数据变更。

仅仅保障了冗余还不够，当零碎中有节点宕机时，还须要有故障转移机制可能主动将宕机节点正在解决的工作转移到新节点上执行。在 DolphinScheduler 中所有的故障转移工作都由 Master 实现。

Master 会监听注册核心中所有 Master 和 Worker 的健康状况，一旦有节点下线，所有 Master 会收到该节点下线的事件，而后执行容错逻辑。

通过竞争分布式锁的形式来决定由谁来进行本次故障转移操作。

在执行容错操作时，会依据 Master/Worker 的类型不同执行不同的容错操作。对于产生 Master 容错时，所有存活的 Master 会通过竞争分布式锁的形式来决定由谁来进行本次故障转移操作，竞争到分布式锁的 Master 会去数据库中查问出宕机节点中正在运行的工作流实例生成容错申请。对于产生 Worker 容错，所有 Master 会找出以后内存中是否有正在该 Worker 上运行的工作，如果有那么触发工作容错逻辑。

一种非凡状况是，可能集群中所有 Master 都宕机了，那么此时没有 Master 能够执行容错逻辑，因而当前面集群复原时，在 Master 启动的时候也会进行容错逻辑。