点击原文：【技术分享】猪八戒基于Quartz分布式调度平台实践

点击关注“八戒技术团队”，阅读更多技术干货

1.背景介绍

1.1 业务场景

调度任务是我们日常开发中非常经典的一个场景，我们时常会需要用到一些不需要在当前请求下立刻执行的任务，或者是需要定时去执行的一些批量业务，比如以下常见调度任务的应用场景：

• 每10秒钟批量定时消息的推送
• 每5分钟级定时数据备份、清理
• 每天需要执行一次生日券的发送
• 每月需要执行一次的月度统计
• 每年需要更新一次的法定节假日

这些定时需要时间/事件驱动的任务，需要一个企业级的调度任务系统提供可视化的定时执行的任务调度器。随着业务量的发展对猪八戒调度平台的健壮性、可用性的要求也日益提高。原有调度系统存在的对第三方依赖较强、调度线程阻塞、任务权责不清晰、告警不及时等问题日益凸显；经过现有的调度平台以及开源的调度平台的框架的调研，大部分开源定时任务框架都是基于Quartz核心调度构建而成。基于公司技术上下文环境，综合考虑接入成本、历史项目的迁移成本，最终选择了基于Quartz进行二次开发，对原调度平台服务端深度重构。

1.2 Quartz框架简介

Quartz本身是一款很优秀并且应用面很广的开源的调度框架，它完全由Java写成，并设计用于J2SE和J2EE应用中。它提供了巨大的灵活性而不牺牲简单性。主要包括三个组件：

调度器(Scheduler)：一个Quartz的独立运行容器，调度器用于将与作业触发器关联；

触发器(Trigger)：触发Job执行的时间触发规则，有SimpleTrigger和CronTrigger两种类型；

作业(Job)：调度执行的具体的作业任务；我们可以用它来为执行一个作业而创建简单的或复杂的调度。它有很多特征，如：数据库支持，集群，插件，EJB作业预构建，JavaMail及其它，支持cron表达式等等。

Quartz框架优点

• 强大的调度功能，例如支持丰富多样的调度方法，可以满足各种常规及特殊需求；
• 灵活的应用方式，例如支持任务和调度的多种组合方式，支持调度数据的多种存储方式；
• 分布式和集群能力，通过数据库的锁机制来确保任务执行的唯一性；
• 作为Spring默认的调度框架，Quartz很容易与Spring集成实现灵活可配置的调度功能。

2.架构设计

基于开源的框架quartz及整合公司现有的一站式开发管理平台，集群化部署，支持水平节点扩展；调度任务基于一致性哈希，将任务加载到本地，按照调度频率分组分片；使用Redis分布式锁作防重复处理，进步进行RPC/HTTP服务调用，针对依赖的第三方进行定时的健康检查，统一的告警处理，完善的节点容错机制等保障系统的高可用。

下面是调度平台核心调度的处理

系统特性：

1.可视化任务管理
2.多机房多活的调度能力
3.调度任务支持立即执行一次
4.任务分组一致性哈希，自动负载均衡
5.支持任务超时机制
6.支持任务重试机制
7.支持任务监控告警

3. 基于Quartz的分布式部署方案拓展实现

3.1 可视化的任务管理

基于公司现有的一站式管理平台调度任务注册时，将调度任务通过域名/DUBBO服务进行服务和工程的绑定，实现工程的可视化管理。

3.2 多机房的多活的调度能力

公司的系统的整体架构是多机房多活的部署，90%以上的调度任务是需要一个节点执行调度任务，而不是需要多节点同时执行调度任务，由此调度平台也需要多活多机房调度的能力并且支持随时切换；针对该问题，我们通过跨机房zk节点的注册管理，控制机房的开闭，应用启动时本机ip匹配机房，确定当前节点的开闭，以此达到控制调度机房开闭的能力。

3.3 水平节点扩容能力

Quartz集群模式下，是通过数据库独占锁来唯一获取任务，任务执行并没有实现完善的负载均衡机制，这种严重依赖数据库锁，当业务量比较大的时候对数据库产生很大的线网压力；针对此问题我们的解决方案是应用启动时我们将所有的任务根据调度频率进行分组进行一致性哈希加载到内存，这样分组后每个节点只需要完成本机负责任务的调度，不用触发时从数据库取锁即可以解决这个问题，同时可通过增加节点的方式增加调度平台的调度能力。

当然这也会引出另外的问题，当我的节点挂掉怎么办？这部分属于节点监控相关的内容，具体场景我们在下面进行说明。除此之外任务触发时我们基于任务ID+应触发时间使用作分布式锁进行任务触发。

3.4 调度线程阻塞解决方案

Quartz核心原理图如下：

使用Quartz的时候我们使用的是SimpleThreadPool作为线程触发的线程池，触发时会获取线程池中的可用线程，假如我们想任务准时准点的触发，就需要将workThread所负责的作业任务尽量异步化，减少同步操作，在此我们采用的是异步RPC的过程。目前我们支持了两种任务类型的异步，一种是Dubbo的RPC调用，一种是Http的异步调用。

3.4.1Dubbo泛化异步调度的支持方案

公司原来的Rpc框架采用的是Dubbo，调度系统通过泛化的方式进行调用，泛化调用方式主要用于客户端没有 API 接口及模型类元的情况，参数及返回值中的所有 POJO 均用 Map 表示，框架集成比较友好，原生并不支持泛化异步调用，基于Dubbo的SPI机制，我们进行二次拓展。首先需要自定义一个dubboFilter实现回调处理的统一入口

其次需要拓展原生的
com.alibaba.dubbo.rpc.support.RpcUtils实现回调参数的传递。

  public static void attachInvocationIdIfAsync(URL url, Invocation inv){
        if (isAttachInvocationId(url, inv) && getInvocationId(inv) == null && inv instanceof RpcInvocation) {
            ((RpcInvocation)inv).setAttachment(Constants.ID_KEY, String.valueOf(INVOKE_ID.getAndIncrement()));
            //进行自定义回调参数信息的传递
           ((RpcInvocation)inv).setAttachment("JobData", RpcContext.getContext().getAttachment("JobData"));
        }
    }

3.4.1HTTP异步调度的支持方案

Dubbo底层的通信框架使用的是netty，Http的异步通信框架我们最终选择的基于netty的async-http-client，通过，设置统一的回调Filter实现统一的回调处理。

3.5 调度监控的实践

刚刚提到应用一启动就进行任务分片，这样会引出当节点连不上zk时，我们需要判断是自己连不上还是所有的节点都连不上zk，假如只有当前节点连不上zk则本机节点需要停止调度，当所有节点都连不上zk的时候我们需要所有的节点保持调度；由此我们针对调度系统所依赖的第三方组件设计了监控模块，该模块采用事件驱动模型设计，针对网络、DB、本机房Dubbo、本机房zk连接进行监控，当检测器发生改变时，发送相应的事件，对应的事件监听器，作出告警或延后触发等相应的节点容错处理.其中zk异常的模块是所以异常中处理相对复杂的模块，假如只有zk异常，并不能影响我们节点的任务触发，以下是zk场景图，当连不上zk的时候，检测节点是否正常，节点之间通过HTTP接口交互。

其他的监控比如网络，当我们监控到网络异常时，首先会发送告警，另外触发器触发时检测网络状态异常，会将任务交由恢复模块待恢复模块监听到网络恢复通知时，进行任务触发补偿处理等。

4. 调度系统的思考和展望

以上是我们基于Quartz实现的分布式调度平台架构的扩展重构，通过无中心化的系统架构、大量的异步操作、事件通知编程模型、节点监控容错、任务的负载均衡等处理实现系统的高可用，目前我们还没有支持广播执行、基于DAG的调度等更加丰富的调度模型，这也是我们后续有可能会去优化的方向。

希望以上内容能对有需要的人有所帮助

欢迎大家留言写下自己希望了解的技术方向

欢迎大家一起探讨交流