定时任务

典型回答 支持！分片任务非常适用于处理大数据量的任务，其实就是可以将一个大任务划分为多个子任务并行执行，以提高效率。 分片任务能更好的利用集群的能力，可以同时调度多个机器并行运行任务。 分片任务的实现原理包括以下几个核心步骤： 任务分配： 当一个分片任务被触发时，调度器会根据任务的分片参数决定需要多少个执行器参与任务。 每个执行器或执行线程会接收到一个分片索引（shard index）和分片总数（shard total）。 分片参数： 分片索引（从0开始）标识了当前执行器处理的是哪一部分数据。 分片总数告诉执行器总共有多少个分片。 并行执行： 每个执行器根据分配到的分片索引并行执行其任务。例如，如果一个任务被分为10个片，那么每个执行器可能负责处理10%的数据。 处理逻辑： 开发者在任务实现时需要根据分片索引和分片总数来调整处理逻辑，确保每个分片处理正确的数据段。 结果汇总： 分片执行完毕后，各个执行器的执行结果可以被独立处理，或者可以通过某种机制进行结果的汇总和整合。 当一个任务被分片任务调度的时候，会带着shardIndex和shardTotal两个参数过来，我们就可以解析这两个参数进行分片执行。 1 2 3 4 5 6 7 8 9 10 11 12 13 public ReturnT<String> orderTimeOutExecute() { int shardIndex = XxlJobHelper.getShardIndex(); int shardTotal = XxlJobHelper.getShardTotal(); if (userId % shardTotal == shardIndex) { // 执行任务 System.out.println("执行任务: 用户 " + userId); } else { // 不执行任务 System.out.println("用户 " + userId + " 不执行任务"); } } 举个例子，假如我们要处理用户订单的关闭任务，就可以用用户 id 对shardTotal取模，然后得到的结果如果和当前的shardIndex相等，则执行，否则不执行。 ...

典型回答 XXL-JOB 作为一个定时任务调度工具，他需要确保同一时间内同一任务只会在一个执行器上执行。这个特性对于避免任务的重复执行非常关键，特别是在分布式环境中，多个执行器实例可能同时运行相同的任务。 这个特性被XXL-JOB描述为“调度一致性”，并且官方文档也给出了这个问题的答案： “调度中心”通过DB锁保证集群分布式调度的一致性, 一次任务调度只会触发一次执行； 调度中心在XXL-JOB中负责管理所有任务的调度，它知道哪些任务需要执行，以及任务的调度配置（如CRON表达式）。当到达指定的执行时间点，调度中心会选择一个执行器实例来执行任务。 调度相关的JobScheduleHelper是XXL-JOB中的一个核心组件，负责协调任务的调度逻辑，确保任务触发的正确性和唯一性。 通过查看JobScheduleHelper的源码，在他的scheduleThread的方法中，我们可以看到以下代码 这里面的select * from xxl_job_lock where lock_name = 'schedule_lock' for update是关键，这明显是一个基于数据的悲观锁实现的一个加锁过程。 xxl_job_lock是XXL-JOB的一张表，是一张任务调度锁表；在使用XXL-JOB的时候需要提前创建好这张表。并且需要提前插入一条记录：INSERT INTO xxl_job_lock ( lock_name) VALUES ( ‘schedule_lock’); 来自 tables_xxl_job.sql 通过select for update的方式添加一个悲观锁，可以确保在同一时刻，只能有一个事务获取到锁。这样获取到锁的线程就可以执行任务的调度了。 ✅乐观锁与悲观锁如何实现？ 并且这个锁会随着事务的存在一直存在，这个事务最最终是在方法的finally中实现的：

典型回答 时间轮算法（Time Wheel Algorithm）是一种用于处理定时任务和调度的常见算法。 时间轮算法主要需要定义一个时间轮盘，在一个时间轮盘中划分出多个槽位，每个槽位表示一个时间段，这个段可以是秒级、分钟级、小时级等等。如以下就是把一个时间轮分为了60个时间槽，每一个槽代表一秒钟。 然后当我们有定时任务需要执行的时候，就把他们挂在到这些槽位中，这个任务将要在哪个槽位中执行，就把他挂在到哪个槽位的链表上。 比如当前如果是0秒，那么要3秒后执行，那就挂在槽位为3的那个位置上。 而随着时间的推移，轮盘不断旋转，任务会被定期触发。 因为这个时间轮是60个槽位，那么他就会在一分钟完整的转完一圈，那么就有一个指针，每一秒钟在槽位中进行一次移动。这个操作是有一个单独的线程来做的，他的工作就是每一秒钟改变一次current指针。 然后还有一个线程池，在指针轮转到某个槽位上的时候，在线程池中执行链表中需要执行的任务。 以上就是一个简单的时间轮算法，但是这个时间轮存在一个问题，那就是我们把它分了60个槽，那么就意味着我们的定时任务最多只支持60s以内的。 那么，怎么解决这个问题呢？ 首先能想到的最简单的方式就是加槽位，比如我要支持5分钟的延迟任务，那么就可以把槽位设置为300个。 还有就是也可以调整时间轮槽位移动的延迟，比如把1秒钟移动一次，改为1分钟移动一次，那么就可以支撑60分钟的延迟任务了。 但是这两个办法都不够灵活，而且是有瓶颈的。于是有一种新的办法。 round 在时间轮中增加一个round的标识，标识运行的圈数，比如说上面的60s的时间轮，如果我要200s之后运行，那么我在设置这个任务的时候，就把他的round设置为 200/60 = 3 ，然后再把它放到 200%60 = 20的这个槽位上。 有了这个round之后，每一次current移动到某个槽位时，检查任务的round是不是为0，如果不为0，则减一。 这样时间轮转到第三圈时，round的值会变成0，再第四圈运行到current=20的时候，发现round=0了，那么就可以执行这个任务了。 这样就解决了我们前面说的问题了。 但是这个方案还存在一个问题，那就是这个round的检查过程，需要把所有任务都遍历一遍，效率还是没那么高。 分层时间轮 为了解决遍历所有任务的问题，我们可以引入分层时间轮。我们在刚刚的秒级时间轮的基础上，在定义一个分钟级时间轮 也就是说我们对于200s以后执行这个任务，我们先把他放到分钟级时间轮上，这个时间轮的槽位每一分钟移动一次，当移动时候，发现某个槽位上有这一分钟内需要执行的任务时。 把这个任务取出来，放到秒级时间轮中。这样在第3分20秒的时候，就可以运行这个任务了。 这就是分层时间轮。在分层时间轮包括多个级别的时间轮，每个级别的时间轮都有不同的粒度和周期。 通常，粒度较细的时间轮拥有更短的周期，而粒度较粗的时间轮拥有更长的周期。例如，分层时间轮可以包括毫秒级、秒级、分钟级等不同粒度的时间轮。 当一个任务需要被调度时，它被分配到适当级别的时间轮中，每个级别的时间轮都独立地旋转。当一个时间轮的指针到达某个位置时，它将触发执行该级别时间轮中的任务。如果某个任务在较粗的时间轮中已经到期，它将被升级到下一级时间轮。 当任务升级到下一级时间轮时，任务的调度粒度变得更细。这意味着任务将在更短的时间内被触发，从而更精确地满足其调度要求。 扩展知识 典型应用 时间轮算法在各种框架和库中都有广泛的应用。以下是一些应用时间轮算法的常见框架和库： Netty：Netty 是一款高性能的网络通信框架，它使用时间轮算法来处理定时任务和超时检测。时间轮用于管理通道的超时和重连机制。 Akka：Akka 是一个并发编程框架，它包括一个调度器，该调度器使用时间轮算法来管理和触发并发任务。这使得 Akka 能够支持高并发和复杂的任务调度需求。 Kafka：Apache Kafka 是一个分布式消息队列系统，它使用时间轮算法来管理消息的过期和删除。时间轮用于清理过期消息，以释放存储空间。 Hystrix：Hystrix 是 Netflix 开发的容错和延迟容忍库，它使用时间轮来管理命令执行和熔断状态的转换。 Disruptor：Disruptor 是一个高性能并发框架，它使用时间轮算法来管理任务的并发执行，以提高处理大量事件的性能。 xxl-job：在以前的版本的xxl-job中，使用quartz做定时任务调度，但是在7.28版本中去除了quartz，改用了时间轮算法。

典型回答 “退避”（Backoff）是在系统发生失败或异常后，延迟一段时间再重试的一种策略。它的核心思想是：不要立即、频繁地重试，而是给系统一点“喘息”的时间，以避免雪崩、资源耗尽或加剧故障。 这是一个在定时任务，重试任务等等系统中非常重要的东西。 假设你调用一个远程服务失败了，如果不做不退避，就是要立即重试，那么就意味着下游服务就要被一直怼，那么就会加剧他的问题，直至崩溃。 而如果使用一定的退避的话，就相当于给对方一点喘息时间、而且也能让自己减少一些无用的调用，提高整体系统的稳定性与容错能力。 在Spring中，其实定义了一些退避策略，给@Retryable注解用的。常见的退避策略有以下几种： 不退避（No Backoff） 不退避，就是直接重试，也算是一种策略。。。。。 固定退避（Fixed Backoff） 每次重试等待相同的时间。这种策略，用起来很简单，但是无法应对持续性故障（比如对方需要更长时间恢复） 指数退避（Exponential Backoff） 等待时间按指数增长：delay = base * (2^n)，其中 n 是重试次数。例如：100ms → 200ms → 400ms → 800ms → … 很多MQ的消息的消费失败的重投，用的就是这种策略，失败次数越多，下次投递的时间窗口就越长。 指数随机退避（ExponentialRandomBackOffPolicy） 指数随机退避。它在指数增长的基础上，增加了一个随机因子，可以避免在重试时多个客户端同时发起请求，造成“惊群效应”。

典型回答 在PowerJob和Schedulerx中都支持MapReduce动态分片。它其实是借鉴了 Hadoop 的 MapReduce 思想 —— 将任务拆分成多个子任务（Map 阶段），并最终将子任务的结果聚合处理（Reduce 阶段），支持数据驱动的分布式计算。 他的主要流程如下： 相比于xxl-job的静态分片任务，他不需要事先设定好分片数，而是根据你输入的数据动态生成子任务，然后再把这些子任务均分给你的具体的执行的实例。这样一来，他就能更好的扩展性，只要你新加了机器，就可以立刻被利用上，而不需要调整分片数。而且不需要把分片数和节点数绑定，不会导致资源的浪费或者不足。 想要在PowerJob中使用mapReduce任务，要继承 MapReduceProcessor 类，实现 map 和 reduce 方法： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 @PowerJob("MapReduceExampleJob") @Slf4j public class MapReduceExampleJob extends MapReduceProcessor { @Override public ProcessResult process(TaskContext context) throws Exception { // 根任务逻辑（可选） return super.process(context); } // Map 阶段：拆分任务 @Override protected List<SubTask> map(TaskContext taskContext) { // 动态生成子任务（示例：拆分10个子任务） List<SubTask> subTasks = new ArrayList<>(); for (int i = 0; i < 10; i++) { subTasks.add(SubTask.create("subTask-" + i, String.valueOf(i))); } return subTasks; } // Reduce 阶段：汇总结果 @Override protected ProcessResult reduce(TaskContext taskContext, List<TaskResult> taskResults) { // 统计子任务结果 int successCount = 0; for (TaskResult result : taskResults) { if (result.isSuccess()) successCount++; } log.info("子任务成功数：{}/{}", successCount, taskResults.size()); return new ProcessResult(true, "汇总成功"); } } 然后控制台上任务类型选择MapReduce就行了。不需要自己手动配置分片数。 ...

典型回答 PowerJob是基于java开发的企业级的分布式任务调度平台，与xxl-job一样，基于web页面实现任务调度配置与记录，使用简单，上手快速。 以下是powerjob自己的文档中，关于几种常见的定时任务的区别： 可以看到，相比于常见的XXL-JOB，有以下几个优势： 1、他支持的定时任务类型更多一些，包括固定频率，固定延时等。 2、他支持MapReduce动态分片，而不是像XXL-JOB一样只支持静态分片 3、他是无锁化设计，相比于XXL-JOB依赖数据库悲观锁性能更好一些。 4、支持的数据库比较多 5、支持DAG工作流 据说（我之前好像看过作者自己写的博客），这个作者是之前到阿里实习，然后发现内部的schedulerx挺强的，离职之后，就参考着自己写了个power-job出来。。。所以不看，大部分功能和schedulerx还是比较像的。

典型回答 Java中的Timer类是一个定时调度器，用于在指定的时间点执行任务。JDK 中Timer类的定义如下： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 public class Timer { /** * The timer task queue. This data structure is shared with the timer * thread. The timer produces tasks, via its various schedule calls, * and the timer thread consumes, executing timer tasks as appropriate, * and removing them from the queue when they're obsolete. */ private final TaskQueue queue = new TaskQueue(); /** * The timer thread. */ private final TimerThread thread = new TimerThread(queue); } 以上就是Timer中最重要的两个成员变量： ...

典型回答 想要用Java中原生的特性实现定时任务，主要有以下几种常见的手段： Timer类和TimerTask类： Timer类是Java SE5之前的一个定时器工具类，可用于执行定时任务。TimerTask类则表示一个可调度的任务，通常通过继承该类来实现自己的任务，然后使用Timer.schedule()方法来安排任务的执行时间。 ✅Java中Timer实现定时调度的原理是什么？ ScheduledExecutorService类： ScheduledExecutorService是Java SE5中新增的一个定时任务执行器，它可以比Timer更精准地执行任务，并支持多个任务并发执行。通过调用ScheduledExecutorService.schedule()或ScheduledExecutorService.scheduleAtFixedRate()方法来安排任务的执行时间。 DelayQueue：DelayQueue是一个带有延迟时间的无界阻塞队列，它的元素必须实现Delayed接口。当从DelayQueue中取出一个元素时，如果其延迟时间还未到达，则会阻塞等待，直到延迟时间到达。因此，我们可以通过将任务封装成实现Delayed接口的元素，将其放入DelayQueue中，再使用一个线程不断地从DelayQueue中取出元素并执行任务，从而实现定时任务的调度。 以上几种方案，相比于xxl-job这种定时任务调度框架来说，他实现起来简单，不须要依赖第三方的调度框架和类库。方案更加轻量级。 当然这个方案也不是没有缺点的，首先，以上方案都是基于JVM内存的，需要把定时任务提前放进去，那如果数据量太大的话，可能会导致OOM的问题；另外，基于JVM内存的方案，一旦机器重启了，里面的数据就都没有了，所以一般都需要配合数据库的持久化一起用，并且在应用启动的时候也需要做重新加载。 还有就是，现在很多应用都是集群部署的，那么集群中多个实例上的多个任务如何配合是一个很大的问题。 扩展知识 以上是在不引入任何其他第三方框架的情况下可以使用的JDK自带的功能实现定时任务，如果可以引入一些常用的类库，如Spring等，还有以下几种方案： Spring的@Scheduled注解： Spring框架提供了一个方便的定时任务调度功能，可以使用@Scheduled注解来实现定时任务。通过在需要执行定时任务的方法上加上@Scheduled注解，并指定执行的时间间隔即可。 Quartz框架： Quartz是一个流行的开源任务调度框架，它支持任务的并发执行和动态调度。通过创建JobDetail和Trigger对象，并将它们交给Scheduler进行调度来实现定时任务。 xxl-job：xxl-job是一款分布式定时任务调度平台，可以实现各种类型的定时任务调度，如定时执行Java代码、调用HTTP接口、执行Shell脚本等。xxl-job采用分布式架构，支持集群部署，可以满足高并发、大数据量的任务调度需求。 Elastic-Job：Elastic-Job是一款分布式任务调度框架，可以实现各种类型的定时任务调度，如简单任务、数据流任务、脚本任务、Spring Bean任务等。Elastic-Job提供了丰富的任务调度策略，可以通过配置cron表达式、固定间隔等方式实现定时任务调度。Elastic-Job支持分布式部署，提供了高可用性和灵活的扩展性，可以满足高并发、大数据量的任务调度需求。

典型回答 定时任务可以定时执行的原理是通过操作系统提供的定时器实现的。定时器是计算机系统的一个重要组成部分，它可以周期性地发出信号或中断，以便操作系统或其他应用程序可以在指定的时间间隔内执行某些任务。 在定时任务中，操作系统或应用程序会利用计时器或定时器来定期检查当前时间是否达到了预定的执行时间，如果当前时间已经达到了预定的时间，系统会自动执行相应的任务。在操作系统中，常见的定时任务管理工具有crontab（Linux系统）、Windows Task Scheduler（Windows系统）等。 总之，定时任务可以定时执行，是因为操作系统或应用程序利用定时器周期性地检查当前时间，一旦达到预定时间就会自动执行相应的任务。 扩展知识 为什么Cron表达式能定时执行 Cron 表达式是我们经常使用的一种表达式，主要用于配置各种定时任务的。 他可以定时执行其实底层也是基于操作系统的定时器的机制。在常见的计算机操作系统中，都提供了一种定时器机制，可以设置定时器来触发某个操作或执行某个任务。Cron 表达式利用这种机制实现了定时执行任务的功能。 具体来说，当我们在系统中设置了一个 Cron 任务后，Cron 服务会根据 Cron 表达式计算出任务下一次应该执行的时间点，并将这个时间点与当前时间点进行比较。如果当前时间点已经超过了任务的执行时间点，那么 Cron 服务会立即执行该任务；否则，Cron 服务会将任务的执行时间点记录下来，并在这个时间点到来时再执行任务。 为了实现这种定时器机制，Cron 表达式通常会被转化为一些特定的参数，然后传递给操作系统或程序库，让它们来设置相应的定时器。不同的操作系统或程序库对于定时器的实现方式可能有所不同，但它们的基本思想都是一致的：在指定的时间点触发一个定时器事件，然后执行相应的任务或操作。 在 Unix/Linux 系统中，Cron 服务通常是通过一个名为 cron 的系统服务来实现的。这个服务会周期性地检查系统中已经配置好的 crontab 文件，根据其中的配置信息来决定哪些任务应该被执行。 crontab 文件中包含了多条定时任务的配置信息，其中每条任务都由五个时间字段和一个命令行指令组成。这五个时间字段分别表示分钟、小时、日期、月份和星期几，cron 会根据这些时间信息来判断任务何时应该被执行。 当定时器达到指定时间时，cron 会根据 crontab 文件中的配置信息，启动相应的命令行指令来执行任务。这样，定时任务就可以按照预定的时间定时执行了。 在 Windows 系统中，Cron 服务通常是通过 Task Scheduler（任务计划程序）来实现的。这个程序也会周期性地检查系统中已经配置好的任务计划，根据其中的配置信息来决定哪些任务应该被执行。

典型回答 通过定时任务扫表，是我们在业务中经常会做的事情，一般是直接用xxl-job等定时任务去分页查询数据库，然后进行业务操作，这个方案，一般是最简单的，也是最有效的。 但是，他还是有一些缺点的，如： 1、数据量多扫表慢 2、集中式扫表会影响正常业务 3、定时扫表存在延迟问题 那么，这几个问题，该如何解决呢？ 数据量多，扫表慢 随着需要扫描的表中的数据量越来越大，通过定时任务扫表的方式会越来越慢，那么想要解决这个问题，首先可以考虑加索引。 我们可以在state字段上增加一个索引，虽然这个字段的区分度不高，但是一般来说，这张表中，SUCCESS的数据量占90%，而INIT的数据量只占10%，而我们扫表的时候只关心INIT即可，所以增加索引后，扫表的效率是可以大大提升的。 ✅区分度不高的字段建索引一定没用吗？ 其次，可以考虑多线程并发扫表，这里可以考虑采用线程池，在任务中开多个线程并发的从数据库中扫描数据进行处理。 但是这样做，会带来一个问题，那就是多个线程之间如何做好隔离，如何确保不会出现并发导致同一条记录被多个线程执行多次呢？ 首先最基本的保障，扫表之后的处理逻辑要做好幂等控制，一旦出现了重复的情况，下游也能因为做了幂等而不会重复处理。 除此以外，在扫表的时候，可以通过分段的思想进行数据隔离。举个例子： 1 2 3 4 5 6 7 8 9 10 11 Long minId = messageService.getMinInitId(); for(int i=1;i<= threadPool.size();i++){ Long maxId = minId + segmentSize()*i; List<Message> messages = messageService.scanInitMessages(minId,maxId); proccee(messages); minId = maxId + 1; } 像上面的例子中，假设有10个线程，那么第一个线程就扫描ID处于0-1000的数据，第二个线程扫描1001-2000的数据，第三个线程扫描2001-3000的数据。这样以此类推，线程之间通过分段的方式就做好了隔离，可以避免同一个数据被多个线程扫描到。 这个做法，有个小问题，那就是INIT的数据的ID可能不是连续的，那么就需要考虑其他的分段方式，比如在事件表中增加一个业务ID，然后根据这个biz_id做分片也可以。 ...