最近在看Apache DolphineScheduler，发现DolphinScheduler在处置惩罚任务时，通过先将任务快速的存储在数据库中，然后基于对应的Task，将Task放入队列中，然后将Task进行快速消耗的思路。
这种模子在很多框架中，都有表现。
我们知道在Master模块时处置惩罚任务的核心模块，而API模块重要是界面中操作的UI逻辑，而Alert模块是告警模块。
因此如果想要了解里面的逻辑，可以通过查看API中工作流的实验可以找到一些线索之外，可以在Master中可以了解到核心的逻辑。
如果想体验相关功能，可以参考官网的搭建过程和相关视频和公众号，这里不展开赘述。
Fetcher突破口
因此我们可以从Fetcher中找到突破口：
告警处置惩罚核心
以AlertEventFetcher为例来了解Apache DolphineScheduler处置惩罚任务/告警/变乱等的原理。
首先我们需要问自己一个问题，告警和Task任务之间又是如何串联起来的？即告警Alert和业务处置惩罚是如何串联起来的？
两者都是随项目模块启动，触发源自于相关工作流和Task处置惩罚的变乱产生的告警信息，实现对应的event变乱，从而进行告警，而告警是通过启动告警模块，进行队列的Put和Take处置惩罚，从而实现对应各个渠道的对接告警。
告警信息的放入：
eventPendingQueue.put(alert)
什么时候会Put？
存在告警数据的时候会put。
List pendingEvents = fetchPendingEvent(eventOffset)
从alertMapper.listingAlertByStatus(minAlertId, AlertStatus.WAIT_EXECUTION.getCode(), QUERY\_ALERT\_THRESHOLD)中获取告警数据。
放入到队列中，核心在saveEvent(AbstractListenerEvent event)
而调用saveEvent(AbstractListenerEvent event)的地方：
状态：alert_status为等候实验的状态。
从这些监听变乱中，我们可以看到这里的监听变乱重要和工作流处置惩罚和Task处置惩罚监听有关，即和Task和Workflow有关，也即我们最核心的业务处置惩罚。
可以根据这些变乱找到对应的变乱找到对应的业务逻辑处置惩罚。
eventPendingQueue.take()的地方在哪里？
org.apache.dolphinscheduler.alert.service.AbstractEventLoop#run。
而调用org.apache.dolphinscheduler.alert.service.AlertEventLoop#handleEvent的地方：
alertChannel.process(alertInfo)这里会根据对应的渠道类型，进行告警。
doSendEvent的地方中有两个地方：
- org.apache.dolphinscheduler.alert.service.AbstractEventSender#sendEvent
- org.apache.dolphinscheduler.alert.service.AlertSender#syncHandler
工作流处置惩罚核心
同理我们可以找到处置惩罚工作流的核心逻辑，串联的要点在于：
commandFetcher.fetchCommands()
因此我们可以思考如何获取对应的command的逻辑，以及获取之后的处置惩罚。
获取command之后，放入到workflowEventQueue队列中。
处置惩罚的核心逻辑在：
org.apache.dolphinscheduler.server.master.runner.WorkflowExecuteRunnable#startWorkflow
过程：
- initTaskQueue
- processStart
- submitPostNode
根据这样的思路可以找到上面相关Fetcher的处置惩罚的核心逻辑。更多细节和详情，可以去官网了解。
参考：
海豚调度官网：https://dolphinscheduler.apache.org/
Github地址：https://github.com/apache/dolphinscheduler
本文由 白鲸开源 提供发布支持！
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
