分布式任务调度(04)--自研

1 背景

兼容技术团队自研的RPC框架，技术团队不需要修改代码，RPC注解方法可以托管在任务调度系统中，直接当做一个任务来执行。

研读XXL-JOB，同时从阿里云分布式任务调度 SchedulerX 吸取。

SchedulerX 1.0 架构图

Schedulerx-console 是任务调度的控制台，用于创建、管理定时任务。负责数据的创建、修改和查询。在产品内部与 schedulerx server 交互。
Schedulerx-server 是任务调度的服务端，是 Scheduler的核心组件。负责客户端任务的调度触发以及任务执行状态的监测。
Schedulerx-client 是任务调度的客户端。每个接入客户端的应用进程就是一个的 Worker。Worker 负责与 Schedulerx-server 建立通信，让 schedulerx-server发现客户端的机器。并向schedulerx-server注册当前应用所在的分组，这样 schedulerx-server才能向客户端定时触发任务。

我们模仿了SchedulerX的模块，架构设计如下图：

选择 RocketMQ 源码的通讯模块 remoting 作为自研调度系统的通讯框架：阅读 SchedulerX 1.0 client 源码中，发现 SchedulerX 的通讯框架和RocketMQ Remoting很多地方都很类似。它的源码里有现成的工程实现。

将 RocketMQ remoting 模块去掉名字服务代码，做定制。

在RocketMQ的remoting里，服务端采用 Processor 模式。

调度中心需要注册两个处理器：回调结果处理器CallBackProcessor和心跳处理器HeartBeatProcessor 。执行器需要注册触发任务处理器TriggerTaskProcessor 。

代码语言：javascript复制

public void registerProcessor(
             int requestCode,
             NettyRequestProcessor processor,
             ExecutorService executor);1.2.3.4.

处理器的接口：

代码语言：javascript复制

Explainpublic interface NettyRequestProcessor {
 RemotingCommand processRequest(
                 ChannelHandlerContext ctx,
                 RemotingCommand request) throws Exception;
 boolean rejectRequest();
}1.2.3.4.5.6.

对于通讯框架来讲，我并不需要关注通讯细节，只需要实现处理器接口即可。

以触发任务处理器TriggerTaskProcessor举例：

搞定网络通讯后，调度器如何设计？最终我还是选择了Quartz 集群模式。主要是基于以下几点原因：

调度量不大的情况下，Quartz 集群模式足够稳定，而且可以兼容原来的XXL-JOB任务；
使用时间轮的话，本身没有足够的实践经验，担心出问题。另外，如何让任务通过不同的调度服务（schedule-server）触发，需要有一个协调器。于是想到Zookeeper。但这样的话，又引入了新的组件。
研发周期不能太长，想快点出成果。

自研版的调度服务花费一个半月上线了。系统运行非常稳定，研发团队接入也很顺畅。调度量也不大，四个月总共接近4000万到5000万之间的调度量。

自研版的瓶颈，我的脑海里经常能看到。数据量大，我可以搞定分库分表，但 Quartz 集群基于行级锁的模式，注定上限不会太高。