Apache DolphinScheduler 工作流查询异常分析与解决方案

问题现象

在Apache DolphinScheduler 3.2.0版本中，用户反馈了两个关键功能出现异常：

1. 工作流定义查询功能：当访问工作流定义页面时，系统抛出"分页查询工作流定义列表错误"异常，具体表现为"Duplicate key"错误。

2. 工作流血缘关系查询功能：访问工作流血缘关系页面时，系统同样抛出"查询血缘失败"异常，同样显示"Duplicate key"错误。

问题根因分析

经过深入分析，这两个问题的根本原因都与数据库中的重复数据有关：

1. 工作流定义查询问题：系统在查询工作流定义时，会关联查询t_ds_schedules表。当该表中存在多个具有相同process_definition_code的记录时，会导致查询结果中出现重复数据。系统随后尝试将这些结果转换为Map结构时，由于键值重复而抛出异常。

2. 工作流血缘关系查询问题：类似地，血缘关系查询在处理工作流节点时，也遇到了重复键值的问题。这表明在t_ds_process_definition或相关表中可能存在重复或冲突的数据。

技术细节

数据库层面

1. 表结构关系：t_ds_process_definition表与t_ds_schedules表通过process_definition_code字段关联。正常情况下，一个工作流定义应该只对应一个调度配置。

2. 异常场景：当系统出现异常操作（如非正常重启、并发操作等）时，可能导致t_ds_schedules表中出现多条具有相同process_definition_code的记录。

代码层面

1. 数据处理逻辑：系统在获取查询结果后，会使用Java Stream API的toMap方法将结果集转换为Map结构。当遇到重复键时，默认的合并策略会抛出IllegalStateException。

2. 防御性编程缺失：当前代码没有对可能的重复数据做预处理，也没有提供自定义的合并策略来处理重复键的情况。

解决方案

临时解决方案

对于已经出现问题的环境，可以采取以下措施：

1. 数据库清理：检查t_ds_schedules表，删除具有相同process_definition_code的重复记录，确保每个工作流定义只对应一个调度配置。

2. 数据验证：编写SQL脚本检查t_ds_process_definition和t_ds_process_definition_log表中的数据一致性。

长期解决方案

从代码层面改进，建议采取以下措施：

1. 查询优化：修改查询SQL，使用DISTINCT关键字或GROUP BY子句确保结果集中不包含重复记录。

2. 防御性编程：在使用Stream API的toMap方法时，提供自定义的合并策略，例如保留第一个或最后一个遇到的重复项，而不是直接抛出异常。

3. 数据校验：在创建或更新调度配置时，增加业务逻辑校验，防止创建重复的调度配置。

最佳实践建议

1. 定期维护：建立定期的数据库维护机制，检查并清理可能的数据不一致问题。

2. 监控告警：实现关键表的唯一性约束监控，当发现违反唯一性约束的数据时及时告警。

3. 升级计划：考虑升级到更高版本，因为后续版本可能已经修复了类似问题。

4. 操作规范：制定严格的操作规范，避免在系统运行期间进行可能导致数据不一致的操作。

总结

Apache DolphinScheduler中工作流查询异常的根本原因是数据库中存在违反业务逻辑的重复数据。这提醒我们在分布式系统开发中，需要特别注意数据一致性问题，并在代码层面做好防御性编程。通过数据库维护和代码改进双管齐下，可以有效预防和解决此类问题。