一种轻量级定时任务实现 | 京东云技术团队

现在市面上有各式各样的分布式定时任务,每个都有其独特的特点,我们这边的项目因为一开始使用的是分布式开源调度框架TBSchedule,但是这个框架依赖ZK,由于ZK的不稳定性和项目老旧无人维护,导致我们的定时任务会偶发出现异常,比如:任务停止、任务项丢失、任务不执行等;

每逢618大促,在单量很大的情况下,如果出现定时任务异常,会导致订单的积压,进而导致订单的履约时效,严重影响商家的履约效率,造成订单取消、客户投诉等;

为了保障整体的稳定性,在改动成本比较小的情况下,达到快速实现,稳定运行,预防这种偶发异常,我们实现了一种轻量级定时任务来进行无缝隙降级;

我们使用的TBSchedule特性:

1.支持集群、分布式

2.灵活的任务分片

3.动态的服务扩容和资源回收

4.支持单个任务线程数的设置和实时调整

我们要实现的功能

1.为了保障单个系统的稳定性,我们去中心化,单独调度自己的系统的任务

2.为了避免ZK的不稳定性,我们通过redis实现注册中心和动态分片功能

3.避免使用timer,改用线程池来控制线程

4.为了减少改造成本,不需要业务系统改动代码,我们自动实现TBSchedule内部方法,保持原来的入参

5.为了支持更多任务,支持动态调整线程数,增加系统的处理能力

方案实现

结果:

1.通过xml配置,引入jar包方式,实现快速接入

2.基本实现TBSchedule主要功能,基础方法和TBSchedule保持一致,无切换成本

3.通过ducc配置,配合应急预案,支持手动或者自动进行降级,无缝衔接,可随时随地操作,为大促保驾护航

4.线上已运行,动态分片稳定,心跳检查及时,随时可降级,帮助订单系统避免多次zk波动带来的影响

通过轻量级的降级,搭配应急预案触发,保障大促的稳定运行!!!!!

后续计划:

1.改用Quartz作为定时任务的触发器(也可搭配easyjob),支持更多形式的定时配置,完美替代TBSchedule;

2.提供可视化界面监控任务的运行情况

作者:京东零售 马成龙

来源:京东云开发者社区

相关推荐
葫芦和十三9 小时前
图解 MongoDB 05|文档模型设计:内嵌 vs 引用,反范式不是免费午餐
后端·mongodb·agent
不能放弃治疗12 小时前
单 Agent 实现模式
后端
IT_陈寒15 小时前
Redis内存爆了,原来我漏掉了这个致命配置
前端·人工智能·后端
fliter15 小时前
最后一块拼图:用 bitvec 构造 IPv4 包,真正做出自己的 Ping
后端
fliter16 小时前
用 Rust 解析并生成 ICMP 包:checksum、nom 与 cookie-factory
后端
蝎子莱莱爱打怪16 小时前
XZLL-IM干货系列 03|消息 ID 设计:一个 UUID 搞不定的事,我用两个 ID 解决了
后端·面试·开源
fliter16 小时前
从 panic 到 Result:用 Rust 重新整理一个 ping 项目的错误处理
后端
森蓝情丶17 小时前
我给 AI 搭了个法庭:一个前端仔的 LangGraph 实战全记录
前端·后端
JensCS猿17 小时前
从 Spring Boot 回看 SSM 框架:手动挡与自动挡的驾驶哲学
后端
爱勇宝17 小时前
干了近 8 年,一夜之间被裁:AI 时代,程序员最该害怕的不是 AI
前端·后端·程序员