Redis实例必须独占物理磁盘设备，共用SATA盘会导致AOF重写耗时增3.2倍并触发“No space left on device”错误；根本原因是AOF子进程、主线程fsync、RDB快照与系统日志争抢同一IO队列；正确做法是每个实例独占SSD/NVMe设备且AOF与RDB路径须同挂载点。
Redis实例必须独占物理磁盘设备
多个Redis节点共用一块SATA盘时，AOF重写会直接拖垮IO队列——实测耗时增加3.2倍，还可能触发No space left on device错误。根本原因在于：AOF重写子进程的顺序写、主线程的fsync调用、RDB快照生成、系统日志写入全部挤在同一个块设备队列里，毫无隔离可言。
正确做法是为每个Redis实例分配独立的SSD或NVMe设备，挂载路径如/data/redis-node-7001。这不是“建议”，而是硬性前提；哪怕用LVM切逻辑卷，只要底层共享同一块物理盘，IO争抢就无法避免。
AOF与RDB路径必须落在同一挂载点
Redis在AOF重写时会先写临时文件，再通过rename原子替换原AOF文件。如果dir和appendfilename配置指向不同挂载点（比如dir /data但appendfilename /tmp/appendonly.aof），rename会失败并报错Invalid argument，导致AOF重写中断。
检查方式很简单：
- 确认
redis.conf中dir值（如/data/redis-node-7001） - 确认
appendfilename是相对路径（如appendonly.aof），而非绝对路径 - 若必须用绝对路径，则确保它和
dir同属一个mount点（可用df -h /path验证）
禁用swap并关闭transparent_hugepage
多租户环境下，任一实例触发swap或THP，都会污染整个主机的内存调度行为，间接放大IO延迟。尤其当某租户突发大量缓存写入，Linux内核可能将其他租户的Redis进程页换出，导致后续读请求卡在swap IO上。
必须在宿主机层面统一关闭：
-
swapoff -a并注释/etc/fstab中所有swap行 echo never > /sys/kernel/mm/transparent_hugepage/enabled- 加到
/etc/rc.local或systemd service中确保开机生效
cgroup v2对IO限速的实际效果有限
有人试图用io.max限制单个Redis进程的IOPS，但实际效果很差——因为Redis的AOF写入是主线程+子进程协同完成，而cgroup v2的IO控制器只对直接发起IO的进程生效，子进程的写入常绕过限制。更关键的是，io.max控制的是“带宽配额”，不是“队列优先级”；当多个实例同时刷盘，低优先级实例仍会抢占IO队列头，造成高优先级租户响应抖动。
所以IO隔离不能靠软限速，只能靠物理分离：一块盘，一个实例，无例外。
