Redis集群参数中，cluster-enabled、cluster-config-file、cluster-node-timeout等不支持热调整，CONFIG SET看似成功实则被忽略；真正可热调的仅timeout、tcp-keepalive、maxmemory-policy等少数非核心参数。
Redis 集群模式下，绝大多数集群相关参数不支持热调整，CONFIG SET 对它们无效 —— 尝试设置会直接报错 ERR Unsupported CONFIG parameter。
哪些集群参数看似能设、实则被忽略
比如 cluster-enabled、cluster-config-file、cluster-node-timeout 这类名字带 cluster- 的配置项，在集群已启动状态下，用 CONFIG SET cluster-node-timeout 5000 看似成功（返回 OK），但实际不会生效。Redis 内部对这些参数做了硬限制：只在启动时读取 redis.conf 中的值，运行时调用 CONFIG SET 不会触发集群逻辑重载。
- 验证方式：执行
CONFIG GET cluster-node-timeout，返回值仍是旧值；同时CLUSTER NODES输出中节点失联判断仍按原 timeout 执行 - 常见误操作：运维脚本里统一用
CONFIG SET批量调参，结果集群超时行为没变，故障恢复延迟依旧 - 根本原因：集群状态机（如故障检测、槽迁移、failover 触发）依赖初始化时加载的结构体字段，运行时修改配置变量不等于重置状态机
真正可热调整的、与集群间接相关的参数
只有少数非核心、不影响拓扑和一致性语义的参数能用 CONFIG SET 动态更新，且需注意作用域：
-
timeout：客户端空闲连接超时（秒），设为0表示禁用。影响所有客户端，包括集群总线通信的 TCP 连接 —— 但注意：它不控制cluster-node-timeout定义的心跳超时 -
tcp-keepalive：TCP 层保活间隔（秒），设为0关闭。对跨机房集群有一定稳定性帮助，但无法替代cluster-node-timeout的逻辑心跳 -
maxmemory-policy：内存淘汰策略。集群中每个节点独立生效，修改后新写入触发淘汰时立即按新策略执行 -
slowlog-log-slower-than和slowlog-max-len：慢日志阈值与长度。调整后新命令立即受控，便于排查集群内某节点响应毛刺
想改 cluster-node-timeout 或槽分配，只能重启或手动干预
没有绕过重启的“热生效”方法。真实生产中可行路径只有两条：
- 滚动重启：逐台执行
redis-cli -p→ 修改对应CONFIG SET cluster-node-timeout 15000 redis.conf文件 →kill -SIGUSR2（或 systemctl reload）触发平滑重启（需确保save配置合理，避免 RDB 阻塞） - 运行时强制干预：用
CLUSTER FAILOVER或CLUSTER RESET重置局部状态，但无法改变超时判定逻辑；槽迁移必须用CLUSTER SETSLOT ... MIGRATING/IMPORTING/NONE+CLUSTER GETKEYSINSLOT+MIGRATE组合手动完成，耗时且易出错 - 关键提醒：
CONFIG REWRITE不会把热设的cluster-*参数写入配置文件 —— 即使你误以为设成功了，重启后还是原始值
集群参数的不可变性不是 Redis 的缺陷，而是为保证分布式状态一致性做的主动约束。别在 CONFIG SET 上浪费排障时间，先查文档确认参数是否标有 “Available in cluster mode: no”。
