Redis集群节点必须单独配置持久化：每个节点需在redis.conf中显式开启appendonly yes和appendfsync everysec，RDB仅作冷备，AOF才是日常数据保护核心，且所有节点必须统一启用aof-use-rdb-preamble以确保兼容性。
Redis集群节点必须单独配置持久化，不能靠集群自动同步
Redis Cluster本身不提供跨节点的持久化协同机制。每个节点都是独立的Redis实例，RDB和AOF配置必须在每个节点的redis.conf中显式开启，集群只负责数据分片与故障转移，不接管落盘逻辑。
常见错误是以为启用了Cluster就“自动有持久化”，结果所有节点仍用默认配置（appendonly no、save被注释），重启后全部清空。
- 主节点和从节点都要分别配置，不能只配主节点——从节点宕机重启后若无本地AOF/RDB，会清空自身数据再从主节点全量同步，可能放大丢失范围
- 各节点配置文件路径需确认，例如Docker部署时容易漏改
/usr/local/etc/redis.conf，而误改宿主机上的文件 - 使用
redis-cli --cluster创建集群后，必须逐个进入节点容器或SSH到对应机器，执行redis-cli -p <port> config set appendonly yes</port>并config rewrite落地
集群环境下AOF比RDB更可靠，但必须设为everysec
appendfsync everysec是集群场景下的唯一合理选择：既避免always对写吞吐的致命拖慢（集群写请求分散但总量大），又规避no在断电时批量丢数的风险。
RDB在Cluster中作用有限——它只做冷备份，不参与日常数据保护。因为：
- 集群重分片（reshard）或故障转移期间，
save触发条件（如save 60 10000）极难稳定满足，导致RDB长期不生成 - 从节点加载RDB快照时会阻塞复制流，影响集群收敛速度
- 单个节点RDB文件不含slot分配信息，无法直接用于集群恢复
验证是否生效：redis-cli -p 7001 config get appendonly和config get appendfsync必须返回yes和everysec。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
Docker部署集群时，volume挂载必须按节点隔离
多个Redis节点共用同一命名卷会导致AOF文件覆盖冲突。例如节点7001和7002都挂载-v redis-data:/data，则它们的appendonly.aof会写入同一路径，最终只剩一个节点的数据。
正确做法是为每个节点分配独立存储路径：
- 使用带序号的命名卷：
-v redis-node1:/data、-v redis-node2:/data - 或绑定宿主机不同目录：
-v /opt/redis/7001:/data、-v /opt/redis/7002:/data - 检查容器内
/data权限：必须为redis:redis可写，否则AOF写入失败且日志静默（仅redis-server启动时提示Can't open the append only file: Permission denied）
混合持久化（aof-use-rdb-preamble）在集群中必须全局一致开启
如果部分节点开启aof-use-rdb-preamble yes，部分关闭，集群重启后会出现AOF解析不兼容：开启的节点能快速加载，未开启的节点需逐条重放命令，恢复时间差可达数分钟，导致集群长时间处于CLUSTERDOWN状态。
该配置影响AOF文件结构，不是运行时开关，必须在redis.conf中设置并重启生效：
- 开启后，AOF文件开头是RDB二进制块，后续才是命令追加——这要求所有节点用相同Redis版本（≥4.0），低版本节点会拒绝加载
- 生产环境务必统一镜像版本，避免因
redis:7.2和redis:7.0混用导致preamble解析失败 - 验证方式：
head -c 100 /data/appendonly.aof | hexdump -C应看到类似5245444953000000...（RDB魔数）
真正容易被忽略的是：集群脑裂（network partition）期间，少数派节点可能产生不一致AOF，此时仅靠持久化无法挽救——必须配合min-replicas-to-write和min-replicas-max-lag限制写入，否则分裂窗口内的数据注定不可逆丢失。
