需求背景
目前各服务里经常会有定时任务相关需求，而定时任务通常要求同时只有一个任务执行，为了保证定时任务高可以通常也需要主备部署，导致开发定义任务时需要考虑锁竞争关系，以及考虑任务执行状态（成功、失败、重试等）。因此考虑实现一个统一的分布式任务调度服务，解决如下问题：
- 支持一次性执行任务（一次性任务可以延迟执行）；
- 支持cron方式定时执行任务；
- 任务分布式执行，高可用支持；
- 支持简单任务状态统一监控（记录执行状态）；
- 支持任务重试机制。
- 技术调研&选型
machinery(开源分布式任务调度框架)
machinery 是一个基于消息队列的分布式任务调度框架，由Server、broker、worker、backend 这么几个概念组成:
- Server：业务模块，生成具体任务，可根据业务逻辑中，按交互进行拆分；
Broker：存储具体序列化后的任务，machinery中目前支持到Redis, AMQP,和SQS；
Worker：工作进程，负责消费者功能，处理具体的任务；
Backend：后端存储，用于存储任务执行状态的数据；
使用使用Server 作为任务生产和任务触发，backend 用作任务运行状态结果存储， machinery分布式框架不能满足定时触发的需求，因此还需要引入cron 定时任务框架，该定时任务框架是基于本地时间的定时任务框架，因此还需要结合分布式锁来保证同时只能触发一次任务。因此整体设计方案大致如下：
由上图我们可以看到系统主要由2部分组成，分布式任务中心和客户端。
分布式任务中心
分布式任务中心用来管理任务、监控、调度、监听任务执行结果等。
- 任务管理：增删查改定时执行任务
- 定时任务监控：监控新的待执行任务，发现后创建新的触发器，失效删除后的定时任务配置
- 推送待执行的任务到消息队列
- 监听任务执行结果
- 接收客户端主动触发推过来的异步任务。
客户端
客户端是分布式任务执行的组成单元，通过监听自己能执行的任务队列，来执行任务
- 任务接收器：接收到任务后将任务分配给worker执行
- 任务执行woker： 负责执行具体的任务
- 执行结果推送：将任务执行结果推送到消息队列
- 一致性任务触发： 部署异步任务只需满足某个条件时，就触发到消息队列中。
任务参数
任务参数1: {“name”:“task1”,“params”:[“params1=x1”,“params2=x2”], “cron_time”:“*/1 * * * ?”}
