最近在看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<T> 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
本文由 白鯨開源 提供釋出支援！