这是我参与「第五届青训营 」伴学笔记创作活动的第 12 天
前言
抖音新年集卡活动 || 支付宝集五福活动
扫描脚本扫描每个用户的集卡信息计算每个用户所得金额。到开奖时间执行定时任务
项目的难点有
- 自动化——开奖和计算金额是全自动的
- 定时执行——定时发奖
- 海量数据——用户量大
- 高效稳定
由此引出分布式定时任务
发展历程
简单的定时任务——每隔5min定时刷新本地缓存
java
Timer timer = new Timer();
timer.schedule(new TimerTask() {
@Override
public void run() {
SyncLocalCache();
}
},5000,5*60*1000);
)
go
var ticker = time.NewTicker(5*time.Minute)
for {
select {
case <-tikcer.C:
SyncLocalCache()
}
}
但以上两种方法只能控制一台电脑上的程序
增加一个需求——定时执行多个任务
如果为每个任务分配一个线程会比较浪费资源,可以使用ScheduledExecutorService
任务调度——Quartz
缺点缺少负载均衡
分布式定时任务
定时任务是指系统为了自动完成特定任务,实时、延时、周期性完成任务调度的过程
分布式定时任务是把分散的、可靠性差的定时任务纳入统一的平台,并实现集群管理调度和分布式部署的一种定时任务的管理方式。
按触发时机分类:
- 定时任务︰特定时间触发,比如今天15:06执行。
- 延时任务:延时触发,比如10s后执行
- 周期任务∶固定周期时间,或固定频率周期调度触发,比如每天12点或者每隔5s执行
执行任务
- 单机任务:随机触发一台机器执行任务,适用于计算量小、并发度低的任务
- 广播任务:广播到所有机器上执行同一个任务,比如所有机器一起清理日志
- Map任务:一个任务可以分出多个子任务,每个子任务负责一部分的计算。适用于计算量大,单机无法满足要求的任务
- MapReduce任务:在Map任务的基础上,还可以对所有子任务的结果做汇总计算,适用于计算量大,并且需要对子任务结果做汇总的任务
业内主流框架
业内流行框架:Xxl-job、SchedulerX、TCT
实现原理
分布式定时任务核心要解决触发、调度、执行三个关键问题
- 触发器:Trigger,解析任务,生成触发事件
- 调度器:Scheduler,分配任务,管理任务生命周期
- 执行器:Executor,获取执行任务单元,执行任务逻辑
- 控制台(Admin),提供任务管理和干预的功能。
数据流
功能架构
控制台
- 任务:Job,任务元数据
- 任务元数据(Job)是用户对任务属性定义,包括任务类型调度时机、执行行为等
- 包括基础信息(任务叫什么名字,任务属于什么业务),调度时机(什么时候进行调度),执行行为(如集五福中的行为就是发奖),执行方式(单机?广播?...)
- 任务实例:JobInstance,任务运行的一个实例,一个任务可以执行多次
- Job_id
- 触发时间
- 状态&结果
- 过程信息
- 任务结果:JobResult,任务实例运行的结果
- 任务历史:JobHistory,用户可以修改任务信息,任务实例对应的任务元数据可以不同,因而使用任务历史存储
触发器
给定一系列任务,解析它们的触发规则,在规定的时间点触发任务的调度
触发器方案一——定期扫描 + 延时消息
Scanner扫描器每隔一段时间从DB中扫描将要执行的任务,将任务信息传给processor,扫描出的任务并不一定要立即执行,因此需要用到延时MQ并对DB中的任务进行修改以免下次又被扫描
触发器方案二——时间轮
时间轮是一个存储环形队列底层,采用数组实现,数组中的每个元素可以存放一个定时任务列表。
目标:遍历任务列表,从中找出当前时间点需触发的任务列表。每次只要找到最近要执行的任务
核心问题
不同业务之间,任务的调度相互影响怎么办?负责扫描和触发的机器挂了怎么办?
为了要避免同一个任务被多次触发
数据库锁
多台机器频繁竞争数据库锁,节点越多性能越差
分布式锁
调度器
资源来源
资源调度
执行器
注册,调度,回调,心跳检测
业务应用
业务场景
订单30min未支付自动关闭,集五福,定时更新游戏内榜单等等
其他解决方案
发货后超过10天未收货时系统自动确认收货
- 使用分布式定时任务的延时任务
- 使用消息队列的延时消息或者定时消息
春节集卡活动统计完成集卡的用户个数和总翻倍数
- 使用分布式定时任务的MapReduce任务
- 使用大数据离线处理引擎Hive离线做统计
- 使用大数据实时处理引擎Flink实时做累计