一. 背景
有一天，同事在进行测试环境项目启动时，发现项目启动不了了，看了一下日志，发现是redis连接不上，测试又特别着急要测试即将上线的项目，因此我快速的开始了bug的解决。我们项目使用的是redis-cluster，一共部署了6个redis，其中四台是master，两台slave，情况如下。
二. 问题解决
2.1 百度
遇到这个问题后第一时间想到的是百度，但是发现搜索了很久都没有一篇与这个问题相似的文章。于是没有办法，只能自己一点点慢慢追踪bug了。
2.2 查看服务器集群信息
根据提示信息，我第一时间想到的是7001结点宕机了，于是登录7001所在服务器，查看了一下集群状态，发现集群健康，然后到redis-cli进入redis中查看集群信息
[root@centos-43 bin]# ./redis-cli -c -p 7001 -h 172.16.1.14
172.16.1.14:7001> cluster nodes
730376eb543eea5d0688493446f7048b05305fb3 172.16.1.15:7002 slave 3250e26afd654e3480dc9592b5bccb0c67b772b5 0 1630052995292 22 connected
3250e26afd654e3480dc9592b5bccb0c67b772b5 172.16.1.18:7005 master - 0 1630052993290 22 connected 5461-10922
98a20c554b733a254b79e7e795b8f81b6e73d0bf 172.16.1.19:7006 slave 5742015521dc500addc090d46c9fa85624f023d9 0 1630052993790 14 connected
e4dce6887c19274e7a5445f7a031dcba05b28e91 172.16.1.14:7001 master - 0 1630052994792 0 connected
ae4dea0536889fa0aa2b18b5900fbf3ef47aeafd 172.16.1.17:7004 master - 0 1630052995393 11 connected 0-5460
5742015521dc500addc090d46c9fa85624f023d9 172.16.1.16:7003 myself,master - 0 0 14 connected 10923-16383
172.16.1.14:7001> cluster info
cluster_state:ok
cluster_slots_assigned:16384
cluster_slots_ok:16384
cluster_slots_pfail:0
cluster_slots_fail:0
cluster_known_nodes:6
cluster_size:4
cluster_current_epoch:23
cluster_my_epoch:23
cluster_stats_messages_sent:433846
cluster_stats_messages_received:525659
集群状态良好。然后再使用Redis Desktop Manager看是否能连接上redis，发现可以正常连接上，又在本地ping了一下172.16.1.14、telnet 172.16.1.14 7001，都能够正常连接。这就感觉很奇怪了，代码也没有改动，redis也是正常启动的，怎么会报错呢?
2.3 查看源码
无奈，只能从源码开始看起，由于问题已经解决，所以我没有异常栈的信息了，因此只能展示报错位置
在JedisClusterConnection的getResourceForSpecificNode方法中，报了IllegalArgumentException，说是Node 172.16.1.14:7001 is unknown to cluster，意思是 172.16.1.14:7001这个结点不能被集群感知到。这个方法里面调用了getResourcePoolForSpecificNode方法
，中间几个追踪的类这里就不多展示，直接到最后的位置，
上面那行代码取出的RedisClusterNode就是从这个nodes参数转换而来的，这个nodes是一个由ip:port为key，JedisPool为value的map。
接下来回过头看getResourcePoolForSpecificNode方法，发现其实就是从nodes这个map里面娶不到传入的那个node，那么为什么会取不到呢？我们去找找这个node是怎么来的。
从异常栈看JedisClusterConnection的getResourceForSpecificNode方法的调用方，可以发现有以下调用链。
追到这个位置后，我打了个断点，启动了一下项目，看了一下代码，重点是在initializeSlotsCach方法里面调用了cache.discoverClusterNodesAndSlots，而这个方法的代码大概的意思是加载了配置里配置的集群信息，之后调用集群中一个结点来获取这个集群中所有的分配了槽的结点并加入上面提到的nodes中。
2.4 得出结论
于是我们可以发现，是在将第二个nodes里的node遍历传入，并判断是否在第一个nodes中，然后报错的，那为什么在第一个nodes中不存在172.16.1.14:7001结点呢？这两个nodes的区别在哪里呢？仔细比对两段添加nodes的代码可以发现，第一个地方传入的时候是直接将集群中所有结点放入进去，而第二个，则对槽进行了判断，这意味着可能有的master结点并没有分配槽，因此这个结点便没有加入到第二个nodes中。
意识到这一点之后，我便去服务器上再看了一眼集群信息，发现172.16.1.14:7001这个结点确实没有分配槽
三. 重新分配槽
redis-cluster的操作是有一个redis-trib.rb脚本，这个脚本里面封装了一些操作，其中就包括了往集群中增加机器后重新分配槽的命令
命令格式： redis-trib.rb reshard 节点h:p （此处可以参考https://blog.csdn.net/weixin_42363154/article/details/112367865这篇文章，讲的很详细）
于是进入到redis-trib.rb所在的服务器，再进入redis-trib.rb的src目录下执行命令
./redis-trib.rb reshard reshard 172.16.1.14:7001
执行完命令后，还有几个选项，包括给这个结点分配的槽数、从其他结点分别转移多少个槽到这个结点等等，一一填写后，执行命令
执行完成后的集群情况如下
可以看到，槽已经重新分配成功，7001结点从其他结点分配过来了0-1364 5461-6826 10923-12287这三个段的槽
redis-cluster弄好之后，重启项目，重启成功！问题解决
四. 总结
测试环境的redis已经使用好几年了，一直都没有问题，不知道是不是因为有人操作过导致这一次问题，因为是测试环境，因此账号密码是内部公开的。