问题排查：发红包一段时间就不能用了

问题：小红包服务一段时间就不能用了，红包发不出去。。。

临时接受排查任务，对项目并不熟悉，首先从日志开始。。。

服务器日志：

 

 从日志看是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过期，发红包业务无法进行。