xxl-job 处理能力提升记录和验证点

        公司目前逐渐慢慢开始推广xxl-job来替换一些其他的定时任务框架，因为我们做了很多告警提示，重试类型，以及扩展了API任务触发方式来满足业务方的需求。同时对于分布式锁业进行来替换（redis和zk）。功能上已经满足公司很多的业务需求，但是在性能瓶颈上遇到了问题。问题出现在mysql上，因为api 投递的任务每天增长数据在300w条任务执行记录，因此在查询上就变的越来越慢。这还只是刚开始，后期还会有其他高频和大数据量的api 投递任务接入进来做一些异步优化，数据量预估5000w-1亿2千万每天。

  初次优化：

                1.提升数据库规格（云产品数据库）

                2.引入MQ缓存一部分数据

                3.使用谷歌限流控制MQ消费频率，保证mysql端在健康范围内

   

    二次优化：

                1.更换执行日志存储方式：MYSQL ——> Hbase  

                2.支持灰度切换存储方式 （hbase/rds，通过任务管理页面-编辑）

      影响点：

                1. 任务回调（日志内容，执行结果）

                2.失败重试（默认类型）

                3.失败告警

                4.当rds存储切换为hbase时，分页查询时执行记录时，会以hbase为主

                5.任务回调时如果存在执行记录在rds时，会将回调结果在rds更改不会产生数据同步行为

                6.hbase对于任务结果丢失标记采用时间范围方式，rds时间范围+执行地址是否存在

                7.失败扫描会调整为两种存储方式同时支持