根本原因是宿主机io路径未优化：需配置noatime挂载、按磁盘类型选io调度器（ssd用none，hdd用mq-deadline）、确保aof目录权限属主为uid 999且可写可执行，并用:z标签适配selinux，同时避免跨文件系统rename。
Redis持久化在Docker中变慢，根本原因不是Redis配置或容器内参数调得不够细，而是宿主机IO路径没理顺——RDB快照和AOF重写时大量小随机写+元数据更新，撞上了默认的ext4挂载选项和过时的IO调度器。
为什么noatime挂载选项比调save策略更关键
数据库类应用频繁读取key，每次访问都会触发atime（access time）更新，导致额外的磁盘写入。对Redis这种每秒数万次GET的场景，这部分开销不可忽略。
- 默认挂载（如
/dev/sdb1 on /data type ext4 (rw,relatime)）会持续刷atime，iostat里%util高但await也高，说明磁盘在忙无效操作 -
noatime禁用atime更新，实测AOF重写期间IOPS下降15–20%，且不破坏语义（Redis本身不依赖atime） - 必须在宿主机fstab或mount命令里加，容器内
mount -o remount,noatime /data通常失败——因为挂载命名空间隔离，且多数容器以read-only方式继承父挂载 - 不要用
strictatime或relatime替代，前者加重负担，后者仍会不定期更新，对高频读无实质改善
宿主机IO调度器选none还是mq-deadline
看磁盘类型，不是看容器跑在哪。SSD/NVMe上用none，HDD才用mq-deadline；选错反而引入延迟。
- 执行
lsblk -d -o name,rota：若rota=0，基本是SSD/NVMe，直接切none；rota=1才是HDD，用mq-deadline -
echo none > /sys/block/sda/queue/scheduler是临时生效，重启丢失；要持久化，写udev规则：ACTION=="add|change", KERNEL=="sda", ATTR{queue/scheduler}="none" - 别在容器里尝试改
/sys/block/...——报Permission denied是常态，因为容器没sys_admin能力，且操作的是虚拟块设备节点 - 验证是否生效：
cat /sys/block/sda/queue/scheduler输出中[none]被方括号包住才算成功
挂载目录权限错误导致AOF写失败的典型现象
容器能启动、redis-cli连得上、INFO显示持久化开启，但AOF文件就是不增长——90%是UID 999没写权限，不是配置漏了appendonly yes。
- 宿主机执行
ls -ld /host/data，确认属主是999或至少chmod 755 /host/data且组可写（Redis镜像默认以redis用户UID 999运行） - 如果目录属主是
root，chown -R 999:999 /host/data，不能只chown 999 /host/data——AOF重写时会生成临时文件，需要父目录可写可执行 - 用
docker run -v /host/data:/data:Z redis加:Z标签在SELinux启用系统上是必要操作，否则Permission denied可能静默失败 - 验证方式：进容器
docker exec -u 999 -it redis-container sh，然后touch /data/testfile，能成功才说明权限闭环
docker run命令里必须带的三个挂载相关参数
只写-v /host/data:/data是危险的起点。缺任意一个，都可能让持久化在高峰期突然中断。
-
-v /host/data:/data:rw显式声明读写，避免某些Docker版本默认挂只读（尤其配合--read-only时） -
--security-opt label=disable（非SELinux环境可省），防止安全模块拦截rename操作——AOF重写依赖原子替换，NFS或某些overlayfs会卡在这一步 -
--tmpfs /data/tmp:exec,size=100m给AOF重写临时文件单独分配内存盘，避免/tmp写满或慢盘拖累，特别是当/host/data本身在机械盘上时
最易被忽略的是AOF重写过程中的rename行为：它要求源和目标在同一文件系统。如果挂载点跨了LV或用了bind mount嵌套，rename()会失败，Redis日志只报Failed to rename temp file，没有更多上下文。
