Connection reset by peer 引发的RedisException: NOAUTH Authentication required..问题的分析与解决

一、问题的产生

我的SpringBoot应用中使用了redisson 2.1.2实现分布式锁功能。
我的redisson初始化时是配置了密码的，先启动redis，再启动应用，一切使用都很正常。
有一天，看到日志里报了如下错误

随后，显示连接redis时缺少密码。可是我的yml配置里是有密码的。

网上关于NOAUTH Authentication required.. 的说法就是配置不正确，或者网络不正常引起的。
而我的日志里的确在报出redis错误之前，出现过长时间的nacos连接不上的问题，那我的redis连接问题，也大概率是与网络问题有关吗？

二、问题定位

于是，我在应用正常使用后，果断关闭了nacos，应用日志的确显示：nacos连接超时。
我猜想是不是长时间的nacos连接超时，导致服务器端做了Connection reset操作，并且把redis的连接也给关闭了。才出现了

org.redisson.client.RedisException: NOAUTH Authentication required…

于是我断开nacos一个晚上，看看第二天会不会出现日志：Connection reset by peer 。
第二天，一看，失望了。并没有出现。
于是我想redis客户端连接redis服务端肯定建立了一个TCP连接，那我怎么知道这个连接呢？于是我搜索了资料，找到了一个指令 client list 。
在登录redis命令行后，输入这个指令，回车，会发现客户端与redis服务端建立的连接，如下图所示：

然后，我想模拟服务器的peer rest操作，但是不知道怎么操作，于是我手动关闭这其中的几个redis连接。
操作命令是：client kill ip:port
于是我疯狂的kill，就在我kill了几个redis的连接后，我的应用日志，赫然出现了：NOAUTH Authentication required..

三、思考与验证

为什么kill连接后，就会出现redis缺失密码的问题呢？
1）难道是我的配置不正确？
2）难道是redisson没有重新发起新的连接吗？
于是我又查看了client list，发现我kill后，新的连接又建立了。
我把日志改成debug级别，找到了 ConnectionWatchdog 中有reconnect方法。当我kill掉连接后，reconnect方法会执行，重新建立了连接。
3）那redisson重新建立的连接和我之前的连接有什么不同呢？为什么新建立的连接就会报：密码缺失？
还好，redssson的配置中，可以为连接设置名称，代码如下：

    @Bean
    public RedissonClient redisLockRegistry() {
        log.error("---------------------------------初始化RedissonClient：{}, {},{}", redidsIP, redisPort, redisPassword);
        Config config = new Config();
        config.useSingleServer().setAddress(redidsIP + ":" + redisPort).setPassword(redisPassword)
                .setDatabase(0).setClientName("robotLock")
                // .setConnectionPoolSize(10).setConnectionMinimumIdleSize(2); 后来才加的
        return Redisson.create(config);
    }

我为我的连接设置robotLock的名称。
我重新启动我的服务，再查看 client list，
果然，我在redis客户端连接列表中看到了名称是robotLock的连接。
然而，当我kill掉它们后，新建的连接，并没有使用我配置的名称。

至此，我们确信，这个问题很可能就是redisson重连redis服务端时，没有使用我的配置信息而建立了连接。导致连接在使用时，又校验了密码，报出了错误：NOAUTH Authentication required..

三、问题的排除

我们尝试把redisson版本升级到最新版本3.26.0。看看是否可以解决此问题。
jar包更新后，发现最新的redisson配置还需要在ip前面增加："redis://“或者"redisson://”，并且各个类的包位置也发生了变化。
不过大体上还好，方法名称和写法都没有大的改变。
重启服务，查看client list，嚯！默认直接建立了24个redisson的连接。并且每个连接都使用了我设置的名称：robotLock。
当我故意kill掉几个连接后，重新建立的连接名称也是robotLock。
再看应用，再也不报错误了。
至此，耗时两三天定位的疑难杂症，被攻破了！

四、总结

在我们排查第三方组件问题时，要抓住主要问题，层层递进。不能天马行空，胡思乱想。否则会很浪费时间。
第三方组件的代码都很规范，但是看方法名，就能对代码的意图略知一二，所以也不用每行代码都看懂。能看懂代码要干啥，即可。
如果出现一些稀奇古怪的问题，直接升级版本，也不是一个坏主意。