我们正在运行一个 7 节点的 redis 集群，所有节点都作为主节点（没有从节点复制）。我们将其用作内存缓存，因此我们在 redis.conf 中注释掉了所有保存，并且我们在 redis.conf 中有以下其他非默认值：
maxmemory: 30gb
maxmemory-policy allkeys-lru
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
cluster-require-full-coverage no
这个集群的客户端是一个 spring-boot rest api 应用程序，使用 spring-data-redis 和 jedis 作为驱动程序。我们主要使用spring缓存注解。
前几天我们遇到了一个问题，其中一位大师倒下了一段时间。在 7 节点集群中，当单个主服务器宕机时，我们注意到涉及 redis 的 api 调用的平均响应时间显着增加，这是我所预料的。
当宕机的 master 重新上线并重新加入集群时，我们的响应时间出现了巨大的峰值。通过 newrelic，我可以看到该应用程序开始进行大量的 redis 集群调用（newrelic 没有告诉我正在使用哪个集群子命令）。我们正常的平均响应时间约为 5 毫秒；在此期间，它上升到 800 毫秒，我们有一些缓慢的示例事务，耗时 > 70 秒。在所有应用 jvm 上，我看到在此期间活动线程的数量从正常的 8-9 跃升至 300 左右。我们已将 tomcat http 线程池配置为最多允许 400 个线程。大约 3 分钟后，问题自行解决，但我现在有人质疑我们选择的缓存解决方案的稳定性。Newrelic 没有提供任何关于长请求的额外时间花费在哪里的洞察力（它'
我已经尝试通过针对开发环境运行一些 jmeter 负载测试来进行重现，虽然我在重新连接 redis-cluster master 时看到了一些适度的响应时间峰值，但我没有看到任何接近我们在生产中看到的东西. 我也遇到过https://github.com/xetorthio/jedis/issues/1108，但我没有从中获得任何有用的见解。我尝试将 spring.redis.cluster.max-redirects 从默认的 5 减少到 0，这似乎对我的负载测试结果没有太大影响。我也不确定更改对我的用例有多合适。