Nacos动态配置刷新导致的服务卡死问题分析

type

status

date

slug

summary

背景

技术背景：Nacos+SpringCloud+redis

某业务需要修改配置，由于需要频繁改动，因此选择配置上云；服务节点数：2+1

灾难在点击发布配置的瞬间，一开始普罗米修斯疯狂报警，线程数飙升，此时下意识认为是配置写错，立即删除新配置进行发布。但报警还在继续，认为是配置没有正确刷新，遂在历史记录中选择回滚。但操作对濒死的服务无效，并且事故开始影响到其他业务。

经检查，此时服务无日志生成，已进入假死状态。受影响的服务仅一个，剩下两个服务正常。

立即下线此服务，选择替补服务上线，经测试服务正常工作。同时开始对案发现场进行分析。

工具：jca4614.jar

dump现场，拿出文件进行分析。

其中有52%的线程处于Waiting on condition状态，对应方法为getBean()

找到这里除框架外我们自己的代码，可以看到线程卡在了A类中的name()方法；

这里粘贴部分代码如下：

根据nacos动态配置刷新的过程可以判断，这里刷新动态配置后，销毁了相关的全部bean，此时业务走到B类，在初始化B类时，调用了这里的构造方法，从而用到了A类中的name()方法。

但是name()方法仅返回了String，一般不会引起死锁，因此我们看向上一层堆栈。

很快定位到问题所在，这里看到在A类中有一个lock的动作，而这里lock是通过redis进行操作：

这里完善一下A中的代码

同时根据堆栈中信息可以得出，这里正在等待redissonClient.getLock(key).lock(time, TimeUnit.MILLISECONDS);

此时基本可以定位到此线程卡死的位置了，再通过kibana查询日志得出，52线程早在凌晨三点便已卡住。

尽管使用了nacos进行动态刷新配置，但此操作仍然不安全，这里redis的操作有小概率没有获得返回结果，导致http超时等待。因此不建议频繁使用nacos进行配置刷新。