@Scheduled定时任务毛刺现状与改进

目录

 项目场景：

问题描述

解决方案：

        改造一:

        改造二：

---

 项目场景：

定时任务现状：每个项目都会有一些配置信息，这些信息我们是都放在一个配置服务中，这个服务会定时从配置表中加载所有配置存入本地JVM内存，以供调用方获取（调用方集成了配置服务的SDK，每隔五分钟都会来拉取自身应用的配置）

配置服务每隔五分钟都会去全量拉取配置表然后替换本地内存中的旧配置，而定时任务使用的是基于@Scheduled注解（基于此改造后支持集群环境下单节点执行），然后搭配 cron 表达式

例如：@Scheduled(cron = "0 0/5 * * * ? ") 此配置含义为：分钟为5以及5的倍数 秒钟为0时执行

---

问题描述

生产中随着配置服务的实例增多，流量监控多出了许多毛刺

注:(此图为已将调用方的cron给错开后所呈现，如是最初版本将每5分钟会"人为”造就一大波请求)

---

解决方案：

        改造一:

                因生产上每5分钟配置中心的应用就会迎来一大波请求，导致压力剧增，并且非5分钟的时间段配置中心是没有什么请求

                据此情况，进行了第一轮改造:
                        将各个调用配置中心的应用 配置不同的cron表达式，例如:
                        A、B服务调用配置中心获取机构白名单配置的定时任务就修改为以下表达式A:25*/4***?  B:207/4x**?
这样配置固然是将各个应用获取配置的时间给错开，但是并没有从根本上解决问题

        改造二：

                对于此类需要去配置中心加载参数的定时任务，采用fixedInterval方式，即以上次执行终点起点来计算下次执行起点时间，这样生产个应用的实例的执行时间就从根本上错开了（且可以人为控制实例的部署时间间隔）

                附上@Scheduled各参数描述：@Scheduled注解各参数详解 - 简书 (jianshu.com)