餐饮网站模板,织梦网站搜索页点击返回首页没有反应,搜索引擎优化的例子,广州建设工程交易中心聘用背景
近期业务中有一个定时任务发现每次服务部署时#xff0c;偶发性的会触发问题#xff0c;这里记录一下问题的跟进解决。
分析现象
该定时任务每2分钟执行一次#xff0c;完成数据的更新处理。同时服务部署了多个服务器节点#xff0c;为保证每次只有一个服务器节点上…背景
近期业务中有一个定时任务发现每次服务部署时偶发性的会触发问题这里记录一下问题的跟进解决。
分析现象
该定时任务每2分钟执行一次完成数据的更新处理。同时服务部署了多个服务器节点为保证每次只有一个服务器节点上的任务在跑引入了基于Redis缓存的分布式锁。 示例源码
Scheduled(cron 10 */2 * * * ?)
public void execute() {String jobName getJobName();DistributeLock lock distributeLock.newLock(getJobKey(), 5 * 60);if (!lock.tryLock()) {logger.info( {} execute get lock faild......, jobName);return;}try {logger.info(execute start........ {}, jobName);long startTime System.currentTimeMillis();doExecute();long endTime System.currentTimeMillis();logger.info(execute end........,time:{} ms, (endTime - startTime));} catch (Exception e) {logger.error(execute error, e);} finally {lock.unlock();}
}当服务部署时分析日志发现存在以下异常。
任务存在开始日志但是缺少执行结束时候的日志。新服务启动后会存在空的运行周期所有的节点获取锁失败。
原因 我们假设任务在具体执行doExecute方法时服务器节点收到了重新部署的命令。
那么此时JVM进程会被kill由于JVM直接被kill并没有任何优雅退出的处理此时也就不会有任务执行结束的日志.同样的上述代码中的finally语句也不会被执行到所以锁就不会被释放。由于锁未被及时释放当下一个2分钟执行周期来到时我们看到上一个锁的时间是5*60s此时是无法获取锁的导致空了一个定时任务周期。
解决方案
方案1缩短锁的持有时间
将锁的持有时间修改为2分钟考虑到通常的节点部署时间是超过2分钟的这样可以保证新服务部署的时候上一个锁是已经过期的。
看似是可以解决问题的那么实际可以的吗。其实不然这种方案是有风险的因为这里忽略了doExecute的实际执行时间。
原有的5分钟是确定任务最长执行时间不会超过5分钟但是将锁过期时间设置2分钟实际是否风险的。
举个例子 10:00 任务1开始执行执行时间为3分钟要到10:03才会结束。 10:02 任务2开始执行此时任务1还在执行但是由于锁已经过期了此时任务2也开始执行要到10:05才会结束。 这就会导致同一时刻会存在重叠的任务在执行。 所以不能冒然调整锁的持有时间。
方案2 利用钩子在服务器停止的时候将锁显示释放
该方案依赖Spring或者JVM的关闭钩子在进程销毁的时候进行一些清理工作。
比如可以依赖Spring的ApplicationListener监听ContextClosedEvent事件。
Component
Slf4j
public class DistributeLockShutdownHook implements ApplicationListenerContextClosedEvent {Overridepublic void onApplicationEvent(ContextClosedEvent event) {log.info(shutdown hook, ContextClosedEvent);// 先判断当前节点是否持有定时任务的锁如果持有// 利用redis缓存的api直接删除定时任务持有的锁// 如果不持有锁不做处理。}
}这样可以保证锁是清理掉的后续启动的节点就可以成功获取锁了。
不过这里有一点要注意在清理时一定是当前节点之前持有了这把锁才清理。否则如果不做判断直接清理就会出现问题这通常与我们服务部署时是按照百分比部署有关系。 10:00 B节点正在执行任务持有锁任务执行3分钟。 10:01 A节点此时要重新部署服务将锁删除 10:02 C节点开始执行任务获取锁成功也开始执行任务。 那么此时也会导致多个任务在重叠执行。
方案3 通过定制化线程池等待当前定时任务执行完成优雅退出
可以看到方案1和方案2当前正在执行的任务都是直接被终止掉了那是否有办法等待当前定时任务执行完成再关闭JVM呢。可以尝试使用以下方案。
首先我们给Spring Schedule定时任务指定了线程池同时配置了线程池的关闭策略和关闭等待时间。
Configuration
public class ThreadPoolTaskSchedulerConfig {Beanpublic ThreadPoolTaskScheduler threadPoolTaskScheduler () {ThreadPoolTaskScheduler threadPoolTaskScheduler new ThreadPoolTaskScheduler();//线程池大小为10threadPoolTaskScheduler.setPoolSize(10);//设置线程名称前缀threadPoolTaskScheduler.setThreadNamePrefix(scheduled-thread-test-);//关键点: 设置线程池关闭的时候等待所有任务都完成再继续销毁其他的BeanthreadPoolTaskScheduler.setWaitForTasksToCompleteOnShutdown(true);//关键点设置线程池中任务的等待时间如果超过这个时候还没有销毁就强制销毁以确保应用最后能够被关闭而不是阻塞住threadPoolTaskScheduler.setAwaitTerminationSeconds(60);threadPoolTaskScheduler.initialize();return threadPoolTaskScheduler;}
}Configuration
public class SchedulerConfig implements SchedulingConfigurer {Resourceprivate ThreadPoolTaskScheduler threadPoolTaskScheduler;Overridepublic void configureTasks(ScheduledTaskRegistrar scheduledTaskRegistrar) {scheduledTaskRegistrar.setTaskScheduler(threadPoolTaskScheduler);}
}然后监听Spring的ContextClosedEvent在其中触发线程池的shutdown方法。
Component
Slf4j
public class ShutdownHookDemo implements ApplicationListenerContextClosedEvent {Resourceprivate ThreadPoolTaskScheduler threadPoolTaskScheduler;Overridepublic void onApplicationEvent(ContextClosedEvent event) {log.info(shutdown hook, ContextClosedEvent);threadPoolTaskScheduler.destroy();}
}对于ThreadPoolTaskScheduler的destroy方法源码如下所示 可以看到会触发ExecutorService的shutDown方法等待任务执行完成。而awaitTerminationIfNecessary方法则是限时等待如果超时则将线程中断。
/*** Calls {code shutdown} when the BeanFactory destroys* the task executor instance.* see #shutdown()*/
Override
public void destroy() {shutdown();
}/*** Perform a shutdown on the underlying ExecutorService.* see java.util.concurrent.ExecutorService#shutdown()* see java.util.concurrent.ExecutorService#shutdownNow()*/
public void shutdown() {if (logger.isInfoEnabled()) {logger.info(Shutting down ExecutorService (this.beanName ! null ? this.beanName : ));}if (this.executor ! null) {if (this.waitForTasksToCompleteOnShutdown) {this.executor.shutdown();}else {for (Runnable remainingTask : this.executor.shutdownNow()) {cancelRemainingTask(remainingTask);}}awaitTerminationIfNecessary(this.executor);}
}private void awaitTerminationIfNecessary(ExecutorService executor) {if (this.awaitTerminationMillis 0) {try {if (!executor.awaitTermination(this.awaitTerminationMillis, TimeUnit.MILLISECONDS)) {if (logger.isWarnEnabled()) {logger.warn(Timed out while waiting for executor (this.beanName ! null ? this.beanName : ) to terminate);}}}catch (InterruptedException ex) {if (logger.isWarnEnabled()) {logger.warn(Interrupted while waiting for executor (this.beanName ! null ? this.beanName : ) to terminate);}Thread.currentThread().interrupt();}}
}这样我们可以根据任务最大的超时时间设置线程池属性在JVM关闭时等待线程池中的任务执行完成。 方案对比
方案3的实现会导致部署时间的增加但是可以确保当前定时任务处理完成。方案1和方案2会对当前任务不做处理同时方案1会存在一定的风险。
可以结合实际业务场景需要进行选择当然这里只有方案3才是优雅退出。
补充
提到优雅退出实际Spring有针对web的优雅退出。
修改application.properties配置文件将server.shutdown从默认的immediate修改为graceful.同时设置等待时间为60s。
也就是说当收到退出请求时如果此时有web请求还在处理那么可最多等待60s后再退出。
server.shutdowngraceful
spring.lifecycle.timeout-per-shutdown-phase60s{name: server.shutdown,type: org.springframework.boot.web.server.Shutdown,description: Type of shutdown that the server will support.,sourceType: org.springframework.boot.autoconfigure.web.ServerProperties,defaultValue: immediate
}{name: spring.lifecycle.timeout-per-shutdown-phase,type: java.time.Duration,description: Timeout for the shutdown of any phase (group of SmartLifecycle beans with the same phase value).,sourceType: org.springframework.boot.autoconfigure.context.LifecycleProperties,defaultValue: 30s
}
当存在一个正在处理的耗时web请求当进程关闭时日志中会包含以下信息
2023-08-05 00:16:32.264 o.s.b.w.e.tomcat.GracefulShutdown : Commencing graceful shutdown. Waiting for active requests to complete
2023-08-05 00:17:32.278 o.s.b.w.e.tomcat.GracefulShutdown: Graceful shutdown aborted with one or more requests still active最后再强调一次这里无论哪一种优雅退出都是针对的kil -15这种操作这是操作系统给了应用进程优雅退出的机会如果是kill -9那么就不存在优雅退出了因为会被立即停止执行。
