业务容忍度决定持久化方案：弱一致性场景可用RDB，强一致性需AOF always；慢盘需调优no-appendfsync-on-rewrite等三项配置；混合持久化仅限Redis 4.0+且需兼容验证；路径权限与SELinux/Docker卷配置常被忽略。
数据丢了能接受几分钟？先看业务容忍度
选AOF还是RDB，第一关不是技术，是业务拍板：你最多能丢多少数据？
比如用户登录态、购物车这类弱一致性场景，5分钟内丢失可接受，RDB完全够用；但支付流水、订单状态变更必须“写即落盘”，那就得上AOF的always模式——哪怕性能打七折也得保命。
-
RDB默认配置下，最坏可能丢掉最近60秒到15分钟的数据（取决于save 60 10000等规则） -
AOF设为appendfsync always时，每次写都刷盘，理论上零丢失；但磁盘扛不住高并发写，容易卡住 - 折中方案
appendfsync everysec：每秒刷一次，实际丢失通常≤2秒，IO压力可控，90%线上服务首选
磁盘IO扛不住？重点盯这三个配置项
不是所有机器都配SSD，机械盘或云盘IOPS低时，AOF很容易拖垮Redis响应。
别只改appendfsync，这三处才是IO瓶颈开关：
-
no-appendfsync-on-rewrite yes：AOF重写期间停掉同步刷盘，避免磁盘双写雪崩（默认关闭，务必打开） -
aof-rewrite-incremental-fsync yes：重写时分批刷盘，减小单次IO压力（Redis 4.0+才支持） -
rdbcompression yes和rdbchecksum yes：RDB压缩和校验虽占CPU，但大幅降低磁盘写入量，对慢盘更友好
实测：在一块普通云盘（100 IOPS）上，关掉no-appendfsync-on-rewrite，BGREWRITEAOF一跑，延迟直接飙到200ms+。
混合持久化不是万能解药，得看Redis版本
Redis 4.0+支持aof-use-rdb-preamble yes，开启后AOF文件前半段是RDB快照，后半段是增量命令——兼顾恢复速度和数据安全。
但它有硬门槛：
- 必须用Redis 4.0或更新版本（
redis-server --version确认） - 开启后，
redis-check-aof工具失效，出问题只能靠redis-check-rdb救急 - 如果从老版本升级，旧AOF文件无法被新混合格式识别，得先执行一次
BGREWRITEAOF生成新文件
一句话：混合模式适合新集群，老系统升级前务必做兼容性验证，别信“开就完事”。
备份和恢复时最容易忽略的路径与权限
配置写对了，dump.rdb或appendonly.aof却写不进磁盘？八成是目录权限或SELinux拦路。
-
dir配置的路径（如/var/lib/redis）必须对redis用户可写，且父目录不能是root-only - CentOS/RHEL启用了SELinux时，需加标签：
chcon -R -t redis_exec_t /var/lib/redis - Docker部署时，挂载卷权限常被忽略：
-v /host/redis-data:/data:Z里的:Z很关键
现象示例：Failed to open the AOF file: Permission denied 或 Can't save in background: fork: Cannot allocate memory（后者常因OOM Killer干掉fork子进程，本质也是资源隔离没配好）。
真正麻烦的从来不是选AOF还是RDB，而是磁盘路径写错、权限漏配、版本不匹配这些一眼扫过去根本看不出毛病的地方。
