实用指南：八股已死、场景当立(场景篇-分布式定时任务篇)

废话不多说，今天更新场景篇-分布式定时任务的知识点，做好了开始发车喽！

一、场景篇-分布式定时任务

1、Q:什么是分布式定时任务？它在微服务/分库分表体系中出现的原因是什么?

A:出现的原因如下：

• 分布式定时任务是指在多台机器、多个进程中按照预定时间或周期触发业务逻辑，并且保证同一任务在同一调度周期内只执行一次。
• 在微服务拆分、分库分表后，单机的本地调度（Timer、ScheduledExecutorService）只能控制本机任务，无法保证全局唯一性，容易出现重复执行、漏执行的问题。因此应该一种跨节点协同的调度方案来建立全局一致的任务触发。

---

2、Q: 列举目前 Java 生态中常用的分布式定时任务框架，并说明它们的定位差异？

A:差异如下:

框架	核心实现方式	主要定位
Quartz（集群模式）‍	基于数据库行锁实现调度器的互斥，支持 Cron、SimpleTrigger	作用最全、可自定义插件，适合复杂调度 与 已有 Quartz 经验 的项目
Elastic‑Job（Lite）‍	基于 Zookeeper实现分片、失效转移，内部仍启用 Quartz 作为调度引擎	轻量级、弹性伸缩、任务分片，适合大规模并行处理 场景
XXL‑Job	调度中心利用DB 锁（或 Quartz）构建任务唯一性，执行器通过 HTTP 拉取任务	UI 管理友好、高效上手，适合中小规模 的业务系统
Spring Task + @Scheduled（配合分布式锁）	依赖 Spring 的 TaskScheduler，结合 Redis/Zookeeper 分布式锁实现互斥	业务代码最简，适用于低并发、对可靠性要求不高 的场景
Timer / ScheduledExecutorService（单机）	JDK 原生达成，不适合 分布式	仅作对比基准

---

3、Q:Quartz 在集群环境下如何保证同一任务只被调度一次？请说明关键配置？

A：答案如下：

• 持久化 JobStore（org.quartz.impl.jdbcjobstore.JobStoreTX）将触发器、作业信息写入同一数据库。
• 调度器在获取触发器时会加行锁（SELECT … FOR UPDATE），只有获取到锁的实例才能执行任务，从而实现 互斥。
• 必须配置 org.quartz.jobStore.isClustered = true、org.quartz.jobStore.clusterCheckinInterval（集群心跳）以及统一的 数据源。
• 通过 DisallowConcurrentExecution 注解防止同一 JobDetail 在同一节点并发执行。

---

4、Q:Elastic‑Job 的核心原理是什么？它是如何实现任务分片与失效转移的？

A：答案如下:

• 注册中心：使用 Zookeeper保存作业设置、分片信息以及节点注册信息。
• 分片机制：作业在启动时会读取 shardingTotalCount，将任务拆分为 N 份，每个实例只负责自己被分配的分片（shardingItemParameters）。
• 失效转移：当某节点失联（ZK 会话失效）后，注册中心会重新计算分片分配，将失效节点的分片重新分配给存活节点，保证任务不丢失。