共计 4599 个字符，预计需要花费 12 分钟才能阅读完成。
单点定时工作
JDK 原生
自从 JDK1.5 之后，提供了 ScheduledExecutorService 代替 TimerTask 来执行定时工作，提供了不错的可靠性。
public class SomeScheduledExecutorService {public static void main(String[] args) {
// 创立工作队列，共 10 个线程
ScheduledExecutorService scheduledExecutorService =
Executors.newScheduledThreadPool(10);
// 执行工作: 1 秒 后开始执行，每 30 秒 执行一次
scheduledExecutorService.scheduleAtFixedRate(() -> {System.out.println("执行工作：" + new Date());
}, 10, 30, TimeUnit.SECONDS);
}
}
Spring Task
Spring Framework自带定时工作，提供了 cron 表达式来实现丰盛定时工作配置。老手举荐应用 https://cron.qqe2.com/ 这个网站来匹配你的cron 表达式。
@Configuration
@EnableScheduling
public class SomeJob {private static final Logger LOGGER = LoggerFactory.getLogger(SomeJob.class);
/**
* 每分钟执行一次（例：18:01:00，18:02:00）* 秒 分钟 小时 日 月 星期 年
*/
@Scheduled(cron = "0 0/1 * * * ? *")
public void someTask() {//...}
}
单点的定时服务在目前微服务的大环境下，利用场景越来越局限，所以尝鲜一下分布式定时工作吧。
基于 Redis 实现
相较于之前两种形式，这种基于 Redis 的实现能够通过多点来减少定时工作，多点生产。然而要做好防备反复生产的筹备。
通过 ZSet 的形式
将定时工作寄存到 ZSet 汇合中，并且将过期工夫存储到 ZSet 的 Score 字段中，而后通过一个循环来判断以后工夫内是否有须要执行的定时工作，如果有则进行执行。
具体实现代码如下：
/**
* Description: 基于 Redis 的 ZSet 的定时工作 .<br>
*
* @author mxy
*/
@Configuration
@EnableScheduling
public class RedisJob {
public static final String JOB_KEY = "redis.job.task";
private static final Logger LOGGER = LoggerFactory.getLogger(RedisJob.class);
@Autowired private StringRedisTemplate stringRedisTemplate;
/**
* 增加工作.
*
* @param task
*/
public void addTask(String task, Instant instant) {stringRedisTemplate.opsForZSet().add(JOB_KEY, task, instant.getEpochSecond());
}
/**
* 定时工作队列生产
* 每分钟生产一次（能够缩短距离到 1s）*/
@Scheduled(cron = "0 0/1 * * * ? *")
public void doDelayQueue() {long nowSecond = Instant.now().getEpochSecond();
// 查问以后工夫的所有工作
Set<String> strings = stringRedisTemplate.opsForZSet().range(JOB_KEY, 0, nowSecond);
for (String task : strings) {
// 开始生产 task
LOGGER.info("执行工作:{}", task);
}
// 删除曾经执行的工作
stringRedisTemplate.opsForZSet().remove(JOB_KEY, 0, nowSecond);
}
}
实用场景如下：
- 订单下单之后 15 分钟后，用户如果没有付钱，零碎须要主动勾销订单。
- 红包 24 小时未被查收，须要提早执退还业务；
- 某个流动指定在某个工夫内失效 & 生效；
劣势是：
- 省去了 MySQL 的查问操作，而使用性能更高的 Redis 做为代替；
- 不会因为停机等起因，脱漏要执行的工作；
键空间告诉的形式
咱们能够通过 Redis 的键空间告诉来实现定时工作，它的实现思路是给所有的定时工作设置一个过期工夫，等到了过期之后，咱们通过订阅过期音讯就能感知到定时工作须要被执行了，此时咱们执行定时工作即可。
默认状况下 Redis 是不开启键空间告诉的，须要咱们通过 config set notify-keyspace-events Ex 的命令手动开启。开启之后定时工作的代码如下:
自定义监听器
/**
* 自定义监听器.
*/
public class KeyExpiredListener extends KeyExpirationEventMessageListener {public KeyExpiredListener(RedisMessageListenerContainer listenerContainer) {super(listenerContainer);
}
@Override
public void onMessage(Message message, byte[] pattern) {
// channel
String channel = new String(message.getChannel(), StandardCharsets.UTF_8);
// 过期的 key
String key = new String(message.getBody(), StandardCharsets.UTF_8);
// todo 你的解决
}
}
设置该监听器
/**
* Description: 通过订阅 Redis 的过期告诉来实现定时工作 .<br>
*
* @author mxy
*/
@Configuration
public class RedisExJob {
@Autowired private RedisConnectionFactory redisConnectionFactory;
@Bean
public RedisMessageListenerContainer redisMessageListenerContainer() {RedisMessageListenerContainer redisMessageListenerContainer = new RedisMessageListenerContainer();
redisMessageListenerContainer.setConnectionFactory(redisConnectionFactory);
return redisMessageListenerContainer;
}
@Bean
public KeyExpiredListener keyExpiredListener() {return new KeyExpiredListener(this.redisMessageListenerContainer());
}
}
Spring 会监听合乎以下格局的 Redis 音讯
private static final Topic TOPIC_ALL_KEYEVENTS = new PatternTopic("__keyevent@*");
基于 Redis 的定时工作可能实用的场景也比拟无限，但实现上绝对简略，但对于性能幂等有很大要求。从应用场景上来说，更应该叫做延时工作。
场景举例:
- 订单下单之后 15 分钟后，用户如果没有付钱，零碎须要主动勾销订单。
- 红包 24 小时未被查收，须要提早执退还业务；
优劣势是：
- 被动触发，对于服务的资源耗费更小；
- Redis 的 Pub/Sub 不牢靠，没有 ACK 机制等，然而个别状况能够容忍；
- 键空间告诉性能会消耗一些 CPU
分布式定时工作
引入分布式定时工作组件 or 中间件
将定时工作作为独自的服务，遏制了反复生产，独立的服务也有利于扩大和保护。
quartz
依赖于 MySQL，应用绝对简略，可多节点部署，通过竞争数据库锁来保障只有一个节点执行工作。没有图形化治理页面，应用绝对麻烦。
elastic-job-lite
依赖于 Zookeeper，通过 zookeeper 的注册与发现，能够动静的增加服务器。
- 多种作业模式
- 生效转移
- 运行状态收集
- 多线程解决数据
- 幂等性
- 容错解决
- 反对 spring 命名空间
- 有图形化治理页面
LTS
依赖于 Zookeeper，集群部署, 能够动静的增加服务器。能够手动减少定时工作，启动和暂停工作。
- 业务日志记录器
- SPI 扩大反对
- 故障转移
- 节点监控
- 多样化工作执行后果反对
- FailStore 容错
- 动静扩容
- 对 spring 绝对敌对
- 有监控和治理图形化界面
xxl-job
国产，依赖于 MySQL, 基于竞争数据库锁保障只有一个节点执行工作，反对程度扩容。能够手动减少定时工作，启动和暂停工作。
- 弹性扩容
- 分片播送
- 故障转移
- Rolling 实时日志
- GLUE（反对在线编辑代码，免公布）
- 工作进度监控
- 工作依赖
- 数据加密
- 邮件报警
- 运行报表
- 优雅停机
- 国际化（中文敌对）
总结
微服务下，举荐应用 xxl-job 这一类组件服务将定时工作正当无效的治理起来。而单点的定时工作有其局限性，实用于规模较小、对将来扩大要求不高的服务。
相对而言，基于 spring task 的定时工作最简略快捷，而 xxl-job 的难度次要体现在集成和调试上。无论是什么样的定时工作，你都须要确保：
- 工作不会因为集群部署而被屡次执行。
- 工作产生异样失去无效的解决
- 工作的解决过慢导致大量积压
- 工作应该在预期的工夫点执行
中间件能够将服务解耦，但减少了复杂度