redis集群快照备份不能直接用save或bgsave，因为集群由多个独立分片组成，单节点bgsave仅备份该节点数据，必须遍历所有主节点逐个触发快照，并统一命名、校验与归档。
Redis集群快照备份为什么不能直接用 SAVE 或 BGSAVE
因为 Redis 集群由多个分片（shard）组成，每个分片是独立的 Redis 实例（通常是 redis-server 进程），没有全局快照命令。对某个节点执行 BGSAVE 只会备份该节点负责的槽位数据，漏掉其他节点就等于丢数据。
所以自动化备份必须遍历所有主节点（master），逐个触发快照，并确保备份路径、文件名、时间戳不冲突。
- 只连一个节点执行
redis-cli -h node1 -p 7001 BGSAVE→ 其他节点数据不会被保存 - 集群配置中若启用了
cluster-enabled yes，CONFIG GET dir返回的是该实例本地目录，不同节点的dir值通常不同 - 脚本需提前确认各节点角色：用
redis-cli -h $host -p $port CLUSTER NODES解析出带master标识且无fail的行
如何用 Shell 脚本获取所有主节点并并发触发 BGSAVE
核心是解析 CLUSTER NODES 输出，提取 IP:PORT 和角色信息。注意字段顺序不稳定，必须靠正则或列定位，不能依赖空格切分。
以下片段可安全提取主节点列表（兼容 Redis 6/7 输出格式）：
redis-cli -h 127.0.0.1 -p 7001 CLUSTER NODES | \
awk '$3 ~ /master/ && !/fail/ {print $2}' | \
sed 's/:[0-9]*//'
但实际使用时建议指定任意一个节点即可，无需硬编码 127.0.0.1:7001 —— 可设为脚本参数或环境变量。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 并发调用
BGSAVE更快，但别用&盲并发：某节点响应慢会导致后续命令堆积，推荐用timeout 10s redis-cli -h $node ... BGSAVE - 执行前先检查
redis-cli是否可用、目标端口是否可达（nc -z $host $port） - 避免在
save正在进行时重复触发：查INFO persistence | grep rdb_bgsave_in_progress，值为1就跳过
备份文件怎么命名和归档才不容易混乱
单个节点的 RDB 文件默认叫 dump.rdb，直接覆盖会丢失历史。必须重命名，且包含足够上下文：节点标识 + 时间戳 + 集群名。
例如将 192.168.1.10:7001 的快照存为 cluster-prod-192.168.1.10-7001-20240520-1423.rdb，比 dump_20240520.rdb 明确得多。
- 用
date +'%Y%m%d-%H%M'而非%s：可读性强，排序自然，且避免纳秒级重复 - 归档前校验文件大小：空文件或小于 1KB 很可能是失败快照，
[[ $(stat -c%s "$file") -lt 1024 ]] && rm "$file" - 压缩可选，但 RDB 本身已二进制压缩，
gzip带来收益有限；若网络传输多，建议用rsync --compress替代本地 gzip
定时任务里跑脚本要注意哪些权限和路径陷阱
crond 默认 PATH 很窄（常不含 /usr/local/bin），redis-cli 找不到是高频报错。同时，脚本内所有路径必须写绝对路径，不能依赖当前工作目录。
- crontab 中显式声明 PATH：
PATH=/usr/local/bin:/usr/bin:/bin - 脚本开头用
cd /data/redis-backup || exit 1切到固定目录，避免dump.rdb写到意外位置 - 日志写入需有写权限：
./backup.sh >> /var/log/redis-backup.log 2>&1，别忘了touch /var/log/redis-backup.log && chown redis:redis - 如果节点启用密码认证，
redis-cli -a $PASS不安全（进程参数可见），改用REDISCLI_AUTH=$PASS redis-cli -h $host -p $port BGSAVE
真正麻烦的不是写脚本，而是验证备份可用性——定期用 redis-check-rdb 扫描归档文件，比等到恢复时才发现损坏强得多。
