如何构建延迟任务调度系统（三）：架构设计

功能设计

系统功能：
延迟任务调度系统提供统一的任务操作接口给业务方调用，业务方可以提交任务，取消任务，查询任务状态。
调度服务属于底层应用，因此采用MQ的方式解耦，所有触发的延迟任务都通过消息的方式发送给业务消费方，
由消费方控制流量，业务幂等。同时也保证了任务的重试机制。

采用技术：elastic-job + db + delayQueue + mq

整体架构

业务调用方

• 业务方在需要延迟任务的时候调用延迟任务服务操作任务
• 触发的延迟任务会放到MQ消息队列里面，由业务方自行消费
• 业务方消费消息处理完成之后，调用延迟任务服务通知处理结果

延迟任务节点

• 以dubbo方式提供延迟任务接口供业务方操作，用于添加延迟任务，取消任务，反馈任务处理结果。
• 集成elastic-job提供数据分片功能，每个节点按照对应分片从数据库加载即将触发的延迟任务放到内存中
• 任务调度触发的延迟任务发送到MQ消息队列中
• 接收业务调用的延迟消息处理结果反馈

Zookeeper

• elastic-job注册中心，存储作业信息

elastic-job

• 高可用的分布式任务调度系统
• 注册任务实例信息和分片信息到zk上

数据分片

• elastic-job作业数据分片
• 节点添加/删除，主节点选举，重新分片

任务加载作业

• 由elastic-job实现，使用数据分片功能，提升系统总吞吐量
• 将未来N分钟内要触发的任务加载到内存中

任务在内存中的存储和调度

• 任务加载作业将未来N分钟内触发的任务加载到内存队列DelayQueue
• 任务调度依靠DelayQueue精确触发

数据库

• 延迟任务持久化，存储任务数据

延迟任务状态

    INIT(1, "初始化"),
    LOAD(2, "任务已加载"),
    SENDING(3, "消息已发放"),
    SUCCESS(4, "业务处理成功"),
    FAIL(5, "业务处理失败"),
    CANCEL(6, "业务取消");

数据库设计

CREATE TABLE `delay_task` (
  `delay_task_id` bigint(20) NOT NULL COMMENT '任务ID',
  `sharding_id` tinyint(4) NOT NULL COMMENT '分片ID',
  `topic` varchar(100) NOT NULL COMMENT '消息topic',
  `tag` varchar(100) NOT NULL COMMENT '消息tag',
  `params` varchar(1000) NOT NULL COMMENT '参数',
  `trigger_time` bigint(19) NOT NULL COMMENT '执行时间',
  `status` tinyint(4) NOT NULL COMMENT '任务状态：1.初始化 2.任务已加载 3.消息已发放 4.业务处理成功 5.业务处理失败',
  `extend_field` varchar(100) NOT NULL COMMENT '扩展属性',
  `create_time` bigint(20) NOT NULL COMMENT '创建时间',
  `op_time` bigint(20) NOT NULL COMMENT '最近一次更新时间',
  `last_ver` int(10) NOT NULL COMMENT '版本号',
  `is_valid` tinyint(2) NOT NULL DEFAULT '1' COMMENT '是否有效 0-失效 1-有效',
  PRIMARY KEY (`delay_task_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='延迟任务表'

数据库设计就一张表delay_task，用来存储延迟任务的数据，包括业务方要消费的消息的tag，topic，以及消息体内容