不能直接全部生效；部分运行时参数如maxmemory可热修改，但cluster-enabled等启动期参数会被拒绝，且CONFIG SET不持久化，需配套CONFIG REWRITE更新配置文件。
CONFIG SET 在 Redis 集群节点上能直接生效吗？
不能一概而论。Redis 的 CONFIG SET 命令在集群模式下**部分参数可热修改，但多数涉及拓扑或持久化行为的配置会被拒绝**。比如 maxmemory、timeout、tcp-keepalive 这类运行时参数通常可以设；但 cluster-enabled、cluster-config-file、port 或 bind 这些启动期绑定项，执行会报错 ERR Unsupported CONFIG parameter 或直接无响应。
关键判断依据是：该参数是否属于 REDIS_COMMAND_LOADING 或 REDIS_COMMAND_MODULE 类别（源码中定义），以及是否被 clusterCommand 显式拦截。实际操作前，先连上节点跑一遍 CONFIG GET xxx 确认存在且非只读。
怎么安全地批量下发 CONFIG SET 到所有集群节点？
靠人工逐台 redis-cli -h node -p port CONFIG SET 不现实，也容易漏节点或顺序错乱。必须借助脚本协调，核心逻辑是：获取当前集群拓扑 → 过滤出主节点（或按需含从节点）→ 并发/串行执行命令 → 校验返回值。
- 用
redis-cli --cluster check或CLUSTER NODES输出解析出所有节点 IP:PORT 和角色（master/slave） - 对每个目标节点，用
redis-cli -h $ip -p $port CONFIG SET $key $value，并检查 stdout 是否含OK，stderr 是否为空 - 加 2 秒超时控制（
--conn-timeout 2），避免某节点假死拖垮整批任务 - 跳过正在 failover 的节点：先查
CLUSTER INFO中cluster_state:ok和cluster_slots_assigned:是否为 16384
为什么改了 CONFIG SET 却没持久化到 redis.conf？
CONFIG SET 是纯内存操作，重启即丢。集群环境下尤其危险——某个节点意外宕机后拉起，会按磁盘上的 redis.conf 加载旧配置，导致集群状态不一致（例如一个节点 maxmemory 是 2G，另一个是 4G，数据倾斜加剧）。
必须配套更新配置文件，否则等于白改：
- 用
CONFIG REWRITE命令将当前运行配置写回redis.conf（前提是启动时用了--config或CONFIG SET支持该路径） - 注意：某些发行版 Redis（如 6.0.9 之前）对注释块处理有 bug，
CONFIG REWRITE可能清空原有注释或格式错乱，建议提前备份redis.conf - 如果节点是 systemd 托管，改完还得
systemctl reload redis或至少kill -USR1 $(pidof redis-server)触发日志重载（不影响配置）
集群场景下哪些 CONFIG SET 参数要特别小心？
不是所有“看起来可设”的参数都适合集群中动态调整。以下几类极易引发槽位迁移异常、心跳中断或客户端路由混乱：
-
cluster-node-timeout：调小可能触发误判故障，调大则延迟发现真实故障；变更后需等cluster-node-timeout / 2时间才能被全网感知 -
cluster-require-full-coverage：从yes改no允许部分槽不可用，但客户端可能收到CLUSTERDOWN后不再重试，得配合应用层降级逻辑 -
maxmemory-policy：主从节点策略不一致时，从库可能因驱逐 key 导致复制流断开（SYNC with master failed） -
notify-keyspace-events：开启后增加 CPU 开销，且事件发布在从节点不生效，集群内事件广播范围不可控
真正动这些参数前，最好在测试集群里用 redis-cli --cluster rebalance 模拟一次槽迁移，观察 INFO replication 和 INFO cluster 输出是否稳定。
