关于java:几种主流的分布式定时任务你知道哪些

单点定时工作

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的难度次要体现在集成和调试上。无论是什么样的定时工作，你都须要确保：

• 工作不会因为集群部署而被屡次执行。
• 工作产生异样失去无效的解决
• 工作的解决过慢导致大量积压
• 工作应该在预期的工夫点执行

中间件能够将服务解耦，但减少了复杂度