分布式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

 

 

posted @ 2022-03-18 16:23  aganippe  阅读(432)  评论(0编辑  收藏  举报