问题:小红包服务一段时间就不能用了,红包发不出去。。。
临时接受排查任务,对项目并不熟悉,首先从日志开始。。。
服务器日志:
从日志看是access_token 失效导致,并查看pod里内存使用,排除内存溢出情况。
部署情况
猜测 :维护access_token更新机制出来问题
查看项目源代码
WorkQyConfigScheduler 类,进行access_token更新机制
@Scheduled(cron = "0/30 * * * * ?")
public void execute() {
......
QyGetToken corpGetToken = stringRedisClient.get(corpTokenKey, QyGetToken.class);
if (corpGetToken == null || stringRedisClient.getExpire(corpTokenKey) <= (30 * 60)) {
corpGetToken = WorkWxClient.getToken( workQyConfig.getCorpId(), workQyConfig.getCorpSecret() );
if (corpGetToken != null && corpGetToken.getErrorCode() != null && corpGetToken.getErrorCode() == 0) {
stringRedisClient.put(corpTokenKey, corpGetToken, Duration.ofSeconds(corpGetToken.getExpiresIn()));
log.info("企业 组织 corp_id = {} 。ACCESS_TOKEN 获取成功。", workQyConfig.getCorpId());
} else {
log.warn("企业 组织 corp_id = {} 。ACCESS_TOKEN 不存在或者即将到期,刷新 ACCESS_TOKEN 失败。result = \n {}", workQyConfig.getCorpId(), JSON.toJSONString(corpGetToken));
}
}
......
}
猜测 :任务挂掉了,没有执行。。。
pod并没有重建或重启,查看日志证明也没有挂掉,
监控一段时间。。。
大概18:20:00之后,依然卡在这里了。
查看其他任务
也是卡在这里了。。。
再次查看源码:
说来也巧。。。
WorkQyConfigInitScheduler 也是0/30。。。
@Scheduled(cron = "0/30 * * * * ?")
public void execute() {
......
//同步组织架构
......
}
看到这里基本上,知道问题所在了,同步组织架构的逻辑耗时太久了!!!
查到问题所在就好办了。
解决:
1修改耗时代码
2调整调度时间
3配置调度 taskScheduler
由于对项目不是很了解,选择增加taskScheduler配置类,再后续项目开发中去重构同步组织架构逻辑
@Configuration
public class TaskSchedulerConfig {
@Bean
public TaskScheduler taskScheduler() {
ThreadPoolTaskScheduler taskScheduler = new ThreadPoolTaskScheduler();
taskScheduler.setPoolSize(2);
return taskScheduler;
}
}
知识扩展
最终,如果没有配置taskScheduler, 默认使用单一线程池处理,由于业务逻辑耗时很长,造成更新token任务迟迟没有执行,token过期,发红包业务无法进行。