一次升级开源框架带来的思考：xxl-job

前言：

        可能发生的问题就一定会发生，永远要对生产环境抱有一颗敬畏的心。基础组件和框架每一次小小的改动都可能造成生产事故产生资损，我们无法保证写出的程序没有bug，能做的只是将bug出现的可能性降到最低，将bug的带来的风险降到最小，每次需求请多和需求方沟通业务相关问题并邀请业务参与到功能验收（测试环节）以及保证原有功能不受影响，不要既是研发又是测试，相信我，一个人的开发和测试是有很大的盲点很容产生bug即便功能上ok你能确定业务场景不会有遗漏的吗（高并发，大数据量能撑得住吗）？邀请业务方找个测试人员，做好代码review！让我们在codeing的路上走的更远。。。

一、概述

XXL-JOB是一个分布式任务调度平台，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。现已开放源代码并接入多家公司线上产品线，开箱即用

                                                                                                                                ——官网的描述

二、 为什么选择xxl-job作为定时任务调度中心

      1.公司现有任务调度使用的第三方付费产品，但是第三已经停止功能升级，因此扩展功能受限  

      2.调研后发现xxl-job在扩展上比较灵活方便，部署简单 （重点：易扩展）

      3.java语言开发

三、使用中发现了哪些问题

      1.集群化部署后出现同一时间点执行多次的情况  （测试使用时，观察执行记录发现，可能和数据库版有关系）

      2.job配置默认设置不合理：路由策略：第一个（默认：会造成所有的任务都有第一个执行进行处理，即便有多个）很容易被任务负责人忽略

      3.任务负责人在配置cron表达式时很容易把低频配成高频  例：5每种  配置成* 0/5 * * * 导致每秒都执行

      4.失败重试的类型：每十秒扫描一次然后触发进行重试，特殊化的重试（固定间隔和自定义重试）当然xxl-job为我们提供了基础的能力拿来即可用，同时使用的开发人员可以根据自身需求去扩展自己想要的功能

      5.xxl-job本身是不支持高并发的，因此在扩展高并发能力的时候要考虑在业务实际使用中会产生的问题，在扩展的功能的过程中开发人员往往专注于功能的实现，而忽略了业务场景。在此环节往往会带来资损风险和意外的情况发生

四、框架在使用中要注意哪些问题

     问题1:  对选用的基础组件框架理解不深

       1.在决定使用新的基础框架要在测试环境或开发环境就模拟生产环境（jdk，系统，db等基础环境）

        2.在测试和试用时，不能单纯的验证功能是否满足，尽量让业务线和测试人员参与进来，单个开发人员去测试不管是场景和业务都是比较单一的，很容产生测试没问题，一部署到生产环境就暴露问题

         3:带着审视的眼光去衡量基础组件的核心业务，这样能够让你更加了解这个基础组件

        4:邀请其他工程师来对这个基础组件进行讨论，可以快速，多面的了解一个组件基本情况和问题   

     问题2. 基础组件使用不当带来的问题

        1.整理使用文档和参考demo

         2.进行使用培训

        3.定期检查和回访确定适用方真实意图

问题3:   对基础组件框架进行功能扩展

         1.功能扩展前先和业务方沟通清楚，明确：业务场景，数据量，失败风险，影响范围

         2.功能的改造，尤其是基础框架功能的扩展和改造必须要保证原有业务和功能不受影响，原有老的业务方使用不受影响

         3.协调测试人员，业务方（老，新：提出需求的业务方）参与测试和功能验收

         4.上线前进行代码review和做好回滚方案，同时对上线时间进行公告确保基础组件框架使用方能够及时观察自身应用是否收到影响

         5.上线尽量灰度上线，可以在灰度工程中验证就要在灰度第一台机器时进行验证，避免造成重大影响

五：xxl-job 改造时核心关注的类

类1：XxlJobScheduler 作为理解核心功能的入口

类2： XxlJobTrigger  触发client执行任务的类

类3: JobApiController  Client任务执行过程中所有的回调都由此类处理（日志，执行结果，自定义的回调等）

类4: JobAlarm 告警接口实现（参考：EmailJobAlarm）由于我们办公使用钉钉，所以扩展了一个钉钉告警

五、核心表结构和注意事项

- xxl_job_lock：任务调度锁表；
- xxl_job_group：执行器信息表，维护任务执行器信息；
- xxl_job_info：调度扩展信息表： 用于保存XXL-JOB调度任务的扩展信息，如任务分组、任务名、机器地址、执行器、执行入参和报警邮件等等；
- xxl_job_log：调度日志表： 用于保存XXL-JOB任务调度的历史信息，如调度结果、执行结果、调度入参、调度机器和执行器等等；
- xxl_job_log_report：调度日志报表：用户存储XXL-JOB任务调度日志的报表，调度中心报表功能页面会用到；
- xxl_job_logglue：任务GLUE日志：用于保存GLUE更新历史，用于支持GLUE的版本回溯功能；
- xxl_job_registry：执行器注册表，维护在线的执行器和调度中心机器地址信息；
- xxl_job_user：系统用户表；

  xxl_job_lock ：

         1.可以使用redis/zk锁来代替（通过过期时间来控制避免发生死锁问题）

         2.锁的复杂读，简单的根据任务ID还是任务ID+将任务参数决定你的任务在同一时刻能够执行次数（建议使用任务id+参数作为锁）

xxl_job_log：

         1.每次任务执行都会形成一条执行记录（执行日志log，请求结果，任务执行结果都会产生读写操作），因此要考虑数据量（日否可以定时清除保存一定时间内的数据）

         2.如果扩展了功能导致高并发形成大数据量产生，此表很容导致数据库瓶颈，可以通过MQ + 将此表迁移到非关系数据库（Hbase/MongoDB）实现此表的dao曾逻辑即可

六、非关系型数据库性能参考