高可用性是 Apache DolphinScheduler 的个性之一。它通过冗余来防止单点问题，所有组件人造反对横向扩容；但仅仅保障了冗余还不够，当零碎中有节点宕机时，还须要有故障转移机制可能主动将宕机节点正在解决的工作转移到新节点上执行，从而实现高可用。
01 DolphinScheduler架构介绍
Apache DolphinScheduler是一个分布式易扩大的工作流编排调度零碎。其外围架构次要由3局部组成：APIServer, Master, Worker。
其中API-Server负责接管所有的用户操作申请，Master负责工作流的编排和调度，Worker负责工作流中工作的执行。整个零碎通过注册中信做服务发现，通过数据库长久化元数据。
一个工作流执行的生命周期如下：
- 在API-Server中创立，并将元数据长久化到DB中。
- 通过手动点击或定时执行生成一个触发工作流执行的Command写入DB。
- Master生产DB中的Command，开始执行工作流，并将工作流中的工作分发给Worker执行。
- 当整个工作流执行完结之后，Master完结工作流的执行。
02 DolphinScheduler集群高可用
分布式系统中必须要思考的因素是零碎整体的高可用（HA）。高可用指的是零碎整体可能对外提供服务的工夫占比很高，零碎因为故障而无奈提供服务的工夫占比很短。
为了保证系统的高可用，架构的一个设计准则是通过冗余来避免出现单点问题。单点问题是指零碎中某一工作组件只有单个实例，如果该实例呈现了故障，那么会导致系统整体不可用。
Apache DolphinScheduler也是通过冗余来防止单点问题，在DolphinScheduler中，所有组件人造就反对横向扩容。
01 API-Server高可用
对于API-Server来说，因为API-Server是一个无状态服务，因而API-Server能够很容易的通过部署多台来保障高可用。在部署多台API-Server之后，只须要将他们注册在同一网关，即可一起对外提供服务。
02 Master高可用
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只会被解决一次。
03 Worker高可用
Worker作为DolphinScheduler中工作执行组件，其扩大比拟容易，这是因为在设计上，Worker次要是被动的接管Master散发的工作，他不会被动去数据库中拉取工作。因而Woker只须要在横向扩容之后注册到注册核心即可，Master会通过注册核心感知到Worker的元数据变更。
03 DS中的Failover实现原理
仅仅保障了冗余还不够，当零碎中有节点宕机时，还须要有故障转移机制可能主动将宕机节点正在解决的工作转移到新节点上执行。在DolphinScheduler中所有的故障转移工作都由Master实现。
Master会监听注册核心中所有Master和Worker的健康状况，一旦有节点下线，所有Master会收到该节点下线的事件，而后执行容错逻辑。
通过竞争分布式锁的形式来决定由谁来进行本次故障转移操作。
在执行容错操作时，会依据Master/Worker的类型不同执行不同的容错操作。对于产生Master容错时，所有存活的Master会通过竞争分布式锁的形式来决定由谁来进行本次故障转移操作，竞争到分布式锁的Master会去数据库中查问出宕机节点中正在运行的工作流实例生成容错申请。对于产生Worker容错，所有Master会找出以后内存中是否有正在该Worker上运行的工作，如果有那么触发工作容错逻辑。
一种非凡状况是，可能集群中所有Master都宕机了，那么此时没有Master能够执行容错逻辑，因而当前面集群复原时，在Master启动的时候也会进行容错逻辑。
本文由 白鲸开源科技 提供公布反对！