Redis 的核心优势在于将数据保存在内存中，单线程事件循环以微秒级延迟处理命令。一旦操作系统把 Redis 进程的部分内存页交换到 Swap 分区，命令执行路径就会引入磁盘 I/O，延迟可能从不足 1 毫秒飙升至数百毫秒甚至秒级。生产环境出现这种情况时，往往表现为偶发超时、连接堆积、客户端重试风暴，最终拖垮整个依赖链。因此，规避 Swap 不是可选项，而是 Redis 容量与稳定性治理的基本要求。
一、Redis 为什么对 Swap 如此敏感
Redis 被设计为纯内存数据库，所有键值对都存储在进程的堆内存中。它的高性能建立在内存随机访问的微秒级延迟之上，一旦数据页被操作系统换出到磁盘，访问路径就变成磁盘寻道加读取，延迟量级完全不可控。对于普通应用程序，偶尔的 Swap 可能只影响某个线程，但对于 Redis 这种以微秒为单位的存储组件，哪怕只有几十兆数据被换出，也会直接击穿性能底线。
更关键的是，Redis 采用单线程模型处理命令。主线程既要读取客户端请求、解析协议、执行数据操作，还要负责写入响应。如果某次内存访问触发缺页中断，主线程会被操作系统挂起，等待磁盘 I/O 完成。这期间所有客户端请求都无法得到处理，表现为连接排队、命令超时。一个本来只需要 0.1 毫秒的 GET 操作，在发生 Swap 时可能会阻塞数百毫秒，影响范围从单条命令扩散到整个实例。
操作系统进行内存回收时，会把长期不活跃或冷门的匿名页交换到 Swap。Redis 的键值访问往往带有热点特征，但冷数据同样占用内存。操作系统的页回收算法无法感知 Redis 的业务热点，只要内存压力达到阈值，就可能把任意数据页换出。这种不可控性决定了必须从系统和应用两个层面共同设置防线，而不是寄希望于内核自动调度。
二、如何快速确认 Redis 是否发生 Swap
判断 Redis 是否被交换，最直接的方法是查看进程状态中的 VmSwap 字段。Linux 内核会为每个进程维护当前被换出到 Swap 的内存大小，单位是 kB。通过读取 /proc/<pid>/status 文件，可以拿到这个值。如果 VmSwap 不为零，说明该进程已经有部分内存页被换出。即使值很小，也说明系统内存压力已经到达危险区间，需要立即排查。
当 Redis 以守护进程方式运行，或者一台机器上有多个 Redis 实例时，可以用下面的脚本批量检查。脚本遍历所有 redis-server 进程，并输出每个进程的常驻内存和 Swap 占用情况。建议把该脚本接入监控系统，每分钟执行一次，并在 Swap 大于 0 时触发告警。
#!/bin/bash
for pid in $(pgrep redis-server); do
swap=$(grep VmSwap /proc/$pid/status 2>/dev/null | awk '{print $2}')
rss=$(grep VmRSS /proc/$pid/status 2>/dev/null | awk '{print $2}')
echo "PID=$pid RSS=${rss} kB Swap=${swap} kB"
done
除了进程级指标，还可以从 Redis 自身的延迟观察中发现问题。执行 redis-cli --latency 可以实时查看命令延迟分布。正常情况下平均延迟应该在 1 毫秒以内，如果出现偶发的高延迟毛刺，再结合 VmSwap 指标，基本可以定位为 Swap 问题。同时，INFO stats 中的 latest_fork_usec 也可以辅助判断，因为 fork 持久化时内存膨胀会加剧 Swap 风险。
三、从操作系统层面降低 Swap 概率
Linux 内核参数 vm.swappiness 控制内存回收时优先回收文件页还是匿名页。该值范围是 0 到 100，值越低，内核越倾向于回收文件页，而不是把匿名页换到 Swap。对于 Redis 这类内存型服务，建议将该值设置为 0 或 1。需要注意的是，旧内核中 vm.swappiness=0 表示尽可能不使用 Swap，而较新的内核中 0 和 1 的语义略有差异，但总体上都是尽量减少交换。
另一个重要参数是 vm.overcommit_memory。Redis 在生成 RDB 或 AOF 重写时，需要调用 fork 创建子进程。子进程会复制父进程的页表，虽然写时复制技术避免了物理内存立刻翻倍，但操作系统在 fork 瞬间会检查可用内存是否满足要求。如果 overcommit 策略过于严格，fork 可能失败，或者系统被迫使用 Swap。建议将该参数设置为 1，允许内核超量分配内存，以换取 fork 的成功率。
# 临时生效 sysctl -w vm.swappiness=1 sysctl -w vm.overcommit_memory=1 # 持久化到 /etc/sysctl.conf echo "vm.swappiness=1" >> /etc/sysctl.conf echo "vm.overcommit_memory=1" >> /etc/sysctl.conf
此外，透明大页（Transparent Huge Pages，THP）也可能间接加剧内存压力。THP 会尝试分配 2MB 的大页，但 Redis 使用 fork 时，大页会增大页表复制开销，并可能造成内存碎片。虽然 THP 不直接导致 Swap，但关闭它可以降低内存管理复杂度。在大多数 Redis 生产环境中，建议通过 echo never > /sys/kernel/mm/transparent_hugepage/enabled 来禁用 THP，并将该操作加入开机启动脚本。
四、从 Redis 配置层面规避 Swap
Redis 自身最重要的防线是 maxmemory。未设置该值时，Redis 会持续使用内存直到耗尽系统资源。必须根据机器可用内存为 Redis 设置明确的使用上限，通常建议将 Redis 实例的最大内存设置为物理内存的 50% 到 70%，给操作系统、持久化 fork 以及监控代理预留空间。例如一台 8GB 内存的服务器，单实例 maxmemory 可设为 4GB 到 5GB。
配合 maxmemory 使用淘汰策略，可以避免达到上限后写入失败或触发操作系统的内存回收。缓存场景推荐 allkeys-lru 或 allkeys-lfu，让 Redis 自动淘汰冷数据。如果数据不允许丢失，则需要使用 noeviction，但此时容量规划必须更加保守，否则写入请求会直接报错。下面是一个典型的 Redis 配置片段。
# Redis 配置文件片段 maxmemory 4gb maxmemory-policy allkeys-lru maxmemory-samples 5 # 如果业务数据不能丢失，可考虑 noeviction，但需要更谨慎的容量规划 # maxmemory-policy noeviction
还需要关注 Redis 的持久化配置。RDB 和 AOF 重写都会触发 fork，fork 期间内存占用理论上可能翻倍。虽然写时复制减少了物理内存复制，但大量写操作会导致父子进程共享页被逐渐复制，最终内存峰值可能接近平时的两倍。因此，在设置 maxmemory 时，必须把持久化峰值内存考虑进去。否则一旦触发 fork，系统可能被迫使用 Swap。
五、内存监控与容量规划
避免 Swap 的根本手段是保证物理内存充足。Redis 提供 INFO memory 命令，可以查看当前内存使用、碎片率、峰值等关键指标。重点关注 used_memory_human、used_memory_rss_human 和 mem_fragmentation_ratio。碎片率长期高于 1.5 说明内存碎片较多，实际占用的 RSS 远大于逻辑数据量，变相加剧了内存压力。
# Memory used_memory:1048576 used_memory_human:1.00M used_memory_rss:2097152 used_memory_rss_human:2.00M mem_fragmentation_ratio:2.00 maxmemory:4294967296 maxmemory_human:4.00G maxmemory_policy:allkeys-lru
容量规划不能只看当前数据量，还要考虑增长趋势。建议预留 30% 以上的内存余量，用于吸收突发的写入高峰和持久化 fork 开销。定期分析 Redis 中的大键和热点键，删除无用数据，可以有效降低内存占用。对于多实例部署，可以使用 redis-cli --bigkeys 扫描大键，并结合业务进行拆分或过期设置。
在容器环境中，如果 Redis 运行在 Kubernetes 或 Docker 下，还要留意 cgroup 内存限制。容器的内存上限不等于宿主机的物理内存，一旦容器内存达到 limit，超出部分可能被 OOM Killer 杀掉，或者在某些配置下被交换到宿主机的 Swap。建议在容器编排中禁用 Swap，或者设置 memory.swap.max=0，强制容器在达到内存上限时触发 OOM 而不是交换。同时，监控容器级别的 container_memory_working_set_bytes 与 Redis 的 used_memory，确保两者之间保持合理差值。
如果已经发现 Redis 进程出现少量 Swap，临时措施是尽快降低内存使用：删除过期键、执行 MEMORY PURGE 或重启实例，但重启会导致短暂不可用。长期方案仍是从系统参数、Redis 配置和容量监控三个维度建立防线。Swap 风险的本质是内存超卖，只要规划得当并持续监控，完全可以避免 Redis 因内存交换而性能雪崩。