分布式crontab架构

1. 架构分析

1.1 传统crontab痛点

• 机器故障，任务停止电镀，甚至cron配置都找不回来
• 任务数量多，单机硬件资源有限，需要人工迁移到其他机器
• 需要人工去机器上配置cron，任务执行状态不方便查看

 

1.2 分布式架构的核心要素

• 调度器：需要高可用，确保不会因为单点故障停止调度
• 执行器：需要扩展性，提供大量任务的并行处理能力

 

1.3 常见开源调度架构

 

 

 

2. 分布式设计

分布式架构下的常见的RPC调用问题：

• 分布式网络环境不可靠，RPC异常属于常态
• master下发任务RPC异常，导致master与worker状态不一致
• worker上报任务RPC异常，导致master状态信息落后

 

异常case举例：

• 状态不一致：master下发任务给node1异常，实际上node1收到并开始执行
• 并发执行：master重试下发任务给node2，结果node1与node2同时执行一个任务
• 状态丢失：master更新zookeeper中任务状态异常，此时master宕机切换standby，任务仍处于旧状态

 

分布式伪命题：

• 但凡需要经过网络的操作，都可能出现异常
• 将应用状态放在存储中，必然会出现内存与存储状态不一致
• 应用直接利用raft管理状态，可以确保最终一直，但是成本太高

 

3. 架构设计

架构简化，减少有状态服务，秉承最终一致性

架构折衷，确保异常可以被程序自我治愈

 

4. 整体架构

4.1 架构模型

 

 

4.2 架构思路

利用etcd同步全量任务列表到所有worker节点

每个worker独立调度全量任务，无需与master产生直接rpc

每个worker利用分布式锁抢占，解决并发调度相同任务的问题

 

4.3 master节点设计

任务管理http接口：新建、修改、查看、删除任务

任务日志http接口：查看任务执行历史日志

任务控制http接口：提供去强制结束任务的接口

实现web管理界面：基于jquery+bootstrap的web控制台，前后端分离

 

 

 

 

4.4 worker节点设计

任务同步：监听etcd中/cron/jobs目录变化

任务调度：基于cron表达式计算，触发过期任务

任务执行：协程池并发执行多任务，基于etcd分布式锁抢占

日志保存：捕获任务执行输出，保存到mongoDB