在 DolphinScheduler 中，当任务执行失败后，系统采取哪些机制来实现失败恢复？请描述其重试策略和恢复流程的具体实现方式。

回答思路

1. 【回答框架 1】DolphinScheduler 对任务失败的处理分为失败重试和失败恢复两个层面。重试是在同一任务实例上按配置策略重新执行，恢复则涉及工作流级别的故障转移和状态补偿。
2. 【回答框架 2】失败重试机制：任务节点可配置重试次数和重试间隔。当任务执行失败时，Master 会根据配置将该任务实例重新提交到队列，等待 Worker 再次执行。重试间隔支持固定间隔或指数退避，避免频繁重试对系统造成压力。重试次数用尽后，任务才被标记为最终失败。
3. 【回答框架 3】工作流失败恢复：若工作流某个任务失败且未配置重试或重试耗尽，DolphinScheduler 支持失败策略，如‘失败结束’或‘继续执行’下游任务。对于失败的工作流实例，可通过补数或手动重跑恢复。此外，任务队列中的实例具有持久化状态，Master 故障时可基于数据库状态恢复调度。
4. 【回答框架 4】任务状态管理：每个任务实例都有全生命周期状态（如提交、运行、失败、成功），状态存储在数据库中，Master 和 Worker 通过心跳协调。失败恢复时，Master 会检查任务状态是否一致，若 Worker 异常退出导致任务状态未更新，会依据任务日志和心跳超时进行状态修正，重新调度或标记失败。
5. 【回答框架 5】针对容错的补充：DolphinScheduler 支持任务失败告警和重跑机制，用户可通过 API 或 UI 触发任务重跑。同时，对于工作流级错误，提供了流程实例的重跑和断点续跑能力，从失败节点或指定节点继续执行。
6. 【关键点 1】重试机制按任务节点配置的重试次数和间隔执行，失败后重新提交任务实例。
7. 【关键点 2】工作流失败恢复依赖任务状态持久化和失败策略，支持失败结束或继续执行下游。
8. 【关键点 3】Master 故障时基于数据库状态恢复调度，Worker 异常通过心跳超时和日志进行状态修正。
9. 【关键点 4】支持手动重跑、断点续跑和补数，用于工作流实例的恢复。
10. 【关键点 5】重试次数用尽后才标记最终失败，期间任务状态全程可查。
11. 【易错点 1】不能将重试视为幂等保证，重试可能带来重复执行，需依赖任务本身幂等设计。
12. 【易错点 2】失败恢复不保证数据一致性，仅保证流程可继续或重试，业务级一致性需额外处理。