从 XXL-job 的架构设计说起
在之前的章节中，我们通过源码分析了 XXL-job 的任务调度流程，即定时任务如何从调度中心触发让客户端执行。并据此引用了官网的架构图：
整体系统架构可以分为两部分：调度中心 和 执行器。
-
调度模块（调度中心）：
- 负责管理调度信息，按照调度配置发出调度请求，自身不承担业务代码。
- 支持可视化、简单且动态地管理调度信息，包括任务新建、更新、删除、GLUE 开发和任务报警等。
- 所有操作都会实时生效，同时支持监控调度结果及执行日志，支持执行器 Failover。
-
执行模块（执行器）：
- 负责接收调度请求并执行任务逻辑。
- 接收'调度中心'的执行请求、终止请求和日志请求等。
调度中心与执行器之间的交互依赖于自研 RPC 模块（xxl-rpc）。一次完整的任务调度通讯流程如下：
- '调度中心'向'执行器'发送 HTTP 调度请求：执行器中接收请求的服务实际上是一个内嵌 Server，默认端口为 9999。
- '执行器'执行任务逻辑。
- '执行器'HTTP 回调'调度中心'调度结果：调度中心中接收回调的服务是对执行器开放的一套 API 服务。
接着我们在另一篇文章中分析了 XXL-job 的路由策略，包括多种策略如 FIRST、ROUND、RANDOM、CONSISTENT_HASH 等。
既然提到路由和容错，执行器自然采用集群部署方式，这也在官方文档中有明确说明。
不同的部署架构
执行器集群部署、调度中心单机部署
在此架构下，执行器是集群形式，调度中心为单机，数据源为 MySQL：
执行器集群部署、调度中心集群部署
设计思想强调将调度行为抽象成'调度中心'公共平台，而平台本身不承担业务逻辑，仅负责发起调度请求；任务则被抽象成分散的 JobHandler，交由'执行器'统一管理。'调度'和'任务'两部分因此得以解耦，从而提高系统的整体稳定性和扩展性。
执行器的集群部署提升了业务系统的可用性，而调度中心的集群部署则增强了调度中心本身的可用性。
注册模型
为了观察注册模型的运行过程，可以在本地运行两个调度中心实例，并将一个任务注册上去。
ER 图
涉及两张核心表：
xxl_job_group：执行器信息表，维护任务执行器信息。xxl_job_registry：执行器注册表，维护在线的执行器和调度中心机器地址信息。
