Apache DolphinScheduler 3.2.x 版本中Worker组随机丢失问题的分析与解决方案

问题现象

在Apache DolphinScheduler 3.2.2版本的生产环境中，部分定时任务会随机出现调度失败的情况，错误日志显示系统无法找到已明确存在的Worker组（如"数仓"和"default"组）。典型错误表现为：

Dispatch task failed, worker group not found.
org.apache.dolphinscheduler.server.master.dispatch.exceptions.WorkerGroupNotFoundException: 
Cannot find worker group: Can not find worker group 数仓

值得注意的是：

1. 受影响Worker组确实存在且正常运行
2. 800+任务使用相同Worker组，仅部分任务随机失败
3. 重试后任务都能成功执行
4. 问题会周期性出现（每天）

根本原因分析

通过深入源码分析和日志排查，发现问题源于Worker节点的负载保护机制与资源同步逻辑的交互问题：

1. 负载保护触发机制
   当Worker节点CPU使用率超过maxSystemCpuUsagePercentageThresholds（默认90%）时，节点会标记为BUSY状态：

   OverLoad: the system cpu usage: 0.990 is over then the maxSystemCpuUsagePercentageThresholds 0.9
   

2. 资源同步逻辑缺陷
   Master节点的LowerWeightHostManager会定期同步Worker资源，其关键逻辑存在两个问题：

   • 对BUSY状态的Worker直接返回Optional.empty()
   • 同步时会先清空workerHostWeightsMap再填充新数据

3. 竞态条件产生
   当所有Worker节点同时处于BUSY状态时：

   if (!hostWeights.isEmpty()) {
       workerHostWeights.put(workerGroup, hostWeights);
   }
   

   会导致该Worker组的记录从workerHostWeightsMap中消失，直到有Worker恢复可用状态。

解决方案与优化建议

临时解决方案

对于3.2.2版本，建议调整以下配置参数：

# 关闭负载保护（需评估风险）
worker.server-load-protection.enabled=false

# 增加工作线程数
worker.exec-threads=500

# 修改满负载策略为继续排队
worker.task-execute-threads-full-policy=CONTINUE

长期改进建议

从架构角度，建议在后续版本中优化以下方面：

1. 资源同步逻辑改进

   • 保留Worker组记录，仅标记不可用状态
   • 实现增量更新而非全量刷新

2. 负载状态处理优化

   • 区分"组不存在"和"节点不可用"两种状态
   • 对BUSY状态实现排队机制而非直接丢弃

3. 心跳机制增强

   • 增加心跳超时判定
   • 实现分级预警（WARN/CRITICAL）

最佳实践

对于高负载环境的生产部署，建议：

1. 资源监控
   建立对以下指标的监控看板：

   • Worker节点CPU/内存使用率
   • 线程池使用情况
   • 任务排队数量

2. 容量规划
   根据业务量合理设置：

   # 建议值为(CPU核心数 * 2 ~ 3)
   worker.exec-threads=200
   
   # 建议设置为实际CPU核心数的80%
   worker.server-load-protection.max-system-cpu-usage-percentage=0.8
   

3. 高可用配置

   • 每个Worker组至少配置3个节点
   • 跨机架/可用区部署

总结

该问题暴露了任务调度系统在资源竞争场景下的状态同步机制缺陷。通过本次分析，我们不仅找到了3.2.x版本的解决方案，也为系统优化提供了方向。建议用户根据实际业务场景选择合适的临时方案，并关注后续版本的官方修复。