Conductor项目任务定义(Task Definition)全面解析

Conductor项目任务定义(Task Definition)全面解析

conductor Conductor is a microservices orchestration engine. conductor 项目地址: https://gitcode.com/gh_mirrors/co/conductor

前言

在分布式工作流引擎Conductor中,任务定义(Task Definition)是构建可靠工作流的基础组件。本文将深入讲解任务定义的各项配置参数及其应用场景,帮助开发者更好地设计和管理工作流中的任务。

什么是任务定义

任务定义用于注册SIMPLE类型任务(即工作线程任务)。Conductor维护了一个用户任务类型的注册表,任何要在工作流中使用的任务类型都必须先进行注册。

注意区分任务定义与工作流定义中的任务配置(Task Configurations),后者是工作流定义的一部分,定义在工作流的tasks属性中。

任务定义详解

基本配置

| 配置项 | 类型 | 说明 | 备注 | |-------|------|------|------| | name | string | 任务名称,需能反映其功能 | 必须唯一 | | description | string | 任务描述 | 可选 | | ownerEmail | string | 任务所属团队的邮箱 | 必填 |

重试机制

| 配置项 | 类型 | 说明 | 默认值 | |-------|------|------|------| | retryCount | number | 任务失败时的重试次数 | 3(最大不超过10) | | retryLogic | string(枚举) | 重试策略 | 见下文 | | retryDelaySeconds | number | 重试前的等待时间 | 60秒 |

重试策略类型

  • FIXED:固定间隔重试,每次等待retryDelaySeconds
  • EXPONENTIAL_BACKOFF:指数退避重试,等待时间为retryDelaySeconds * (2 ^ 重试次数)
  • LINEAR_BACKOFF:线性退避重试,等待时间为retryDelaySeconds * 退避率 * 重试次数

超时控制

| 配置项 | 类型 | 说明 | 默认值 | |-------|------|------|------| | timeoutPolicy | string(枚举) | 任务超时策略 | TIME_OUT_WF | | timeoutSeconds | number | 任务超时时间(秒) | 0表示不超时 | | responseTimeoutSeconds | number | 任务响应超时时间(秒) | 600 | | pollTimeoutSeconds | number | 任务轮询超时时间(秒) | 0表示不超时 |

超时策略类型

  • RETRY:任务超时后重试
  • TIME_OUT_WF:工作流标记为超时并终止(默认)
  • ALERT_ONLY:仅记录超时计数器

输入输出定义

| 配置项 | 类型 | 说明 | 备注 | |-------|------|------|------| | inputKeys | string数组 | 任务预期输入键 | 可选 | | outputKeys | string数组 | 任务预期输出键 | 可选 | | inputTemplate | object | 默认输入值 | 可选 |

输入输出键的作用

  • 可以视为任务的参数和返回值
  • 目前不强制要求严格匹配,主要作为文档使用
  • 未来可能发展为严格的接口定义

输入模板示例

"inputTemplate": {
    "apiEndpoint": "https://api.example.com/v1"
}

执行限制

| 配置项 | 类型 | 说明 | 备注 | |-------|------|------|------| | concurrentExecLimit | number | 并发执行限制数 | 可选 | | rateLimitFrequencyInSeconds | number | 限频时间窗口(秒) | 仅Redis持久化支持 | | rateLimitPerFrequency | number | 时间窗口内最大任务数 | 仅Redis持久化支持 |

并发执行限制: 设置concurrentExecLimit=10时,即使有1000个任务在队列中等待,同时有1000个工作线程在轮询,也只会分配10个任务给工作线程执行。

速率限制示例

  • rateLimitFrequencyInSeconds=5
  • rateLimitPerFrequency=12

表示每5秒时间窗口内最多分配12个任务,即每分钟最多144个任务(12*(60/5))。

完整示例

{
  "name": "video_encoding_task",
  "retryCount": 3,
  "timeoutSeconds": 1800,
  "inputKeys": [
    "videoId",
    "resolution",
    "format"
  ],
  "outputKeys": [
    "status",
    "outputUrl",
    "fileSize"
  ],
  "timeoutPolicy": "TIME_OUT_WF",
  "retryLogic": "EXPONENTIAL_BACKOFF",
  "retryDelaySeconds": 300,
  "responseTimeoutSeconds": 3600,
  "pollTimeoutSeconds": 3600,
  "concurrentExecLimit": 50,
  "rateLimitFrequencyInSeconds": 60,
  "rateLimitPerFrequency": 100,
  "ownerEmail": "video-team@company.com",
  "description": "视频转码任务,支持多种分辨率和格式"
}

最佳实践

  1. 合理设置重试策略:对于网络依赖型任务,建议使用指数退避策略
  2. 控制并发数:根据下游系统处理能力设置合适的并发限制
  3. 明确输入输出:即使不强制要求,也应完整定义输入输出键以方便维护
  4. 设置合理的超时:根据任务实际执行时间设置超时,避免资源浪费
  5. 使用速率限制:对可能突发流量的任务实施速率控制

通过合理配置任务定义,可以构建出健壮、可靠的工作流系统,有效管理分布式任务执行。

conductor Conductor is a microservices orchestration engine. conductor 项目地址: https://gitcode.com/gh_mirrors/co/conductor

创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

赖旦轩

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值