Redis无maxmemory配置会自动淘汰吗？

Redis在未显式配置maxmemory时，根本不会启动任何内存淘汰机制——默认的noeviction策略意味着它既不主动驱逐key，也不做任何内存释放尝试，而是持续分配内存直至触发系统级OOM Killer强制杀进程，造成生产环境中难以察觉的“静默崩溃”；这一设计并非疏忽，而是将内存上限视为严格的业务契约，要求运维必须根据实际RSS（而非系统可用内存）精准设定字节级maxmemory值，并理解淘汰仅在写命令执行时同步触发、存在固有延迟等关键行为边界，否则即使配置了淘汰策略也形同虚设。

Redis不设maxmemory时根本不会触发淘汰机制

不会。Redis在未配置maxmemory时，**默认策略是noeviction，且不启动任何内存淘汰逻辑**——它既不会主动删key，也不会因内存增长而自动释放空间。此时Redis会持续申请内存，直到操作系统OOM Killer介入并强杀进程，这是生产环境最典型的“静默崩溃”源头之一。

• 64位系统下，Redis进程可申请的虚拟内存近乎无限（受限于系统总内存和swap），但物理内存耗尽后，Linux内核会根据vm.oom_kill_score_adj选择进程kill，Redis常因RSS高被优先干掉
• INFO memory中used_memory持续上涨、mem_allocator无异常，但evicted_keys始终为0，就是没启用淘汰的铁证
• 哪怕你配了maxmemory-policy volatile-lru，只要没设maxmemory，这条策略完全不生效

为什么maxmemory必须显式配置，不能依赖默认值

Redis设计上把内存上限视为“业务契约”，而非运行时自适应参数。没有maxmemory，就等于告诉Redis：“你爱用多少用多少”，而它真会照做——尤其在缓存场景下，一个SET bigdata "..."可能瞬间吃掉数GB内存。

• 默认不设maxmemory ≠ 安全，默认是“放任”，不是“智能”
• 容器环境（如Docker）中若只限制cgroup memory，但Redis内部无maxmemory，会导致Redis在OOM前仍不断触发内存分配失败（malloc返回NULL），引发不可预测的断连或命令拒绝
• 某些云托管Redis服务（如阿里云Tair、腾讯云CKV）会强制要求设置maxmemory，否则拒绝创建实例

maxmemory该设多大：看RSS，别信“可用内存”

别直接填free -h里显示的“available”，要按Redis进程实际RSS（Resident Set Size）预留余量。因为Redis的内存使用包含碎片、元数据、AOF缓冲、复制积压缓冲等隐藏开销，通常比used_memory高15%–30%。

• 用ps -o pid,rss,comm -C redis-server查当前RSS，再加20%作为maxmemory目标值（例如RSS=3.2GB → 设maxmemory 4gb）
• 若启用了RDB/AOF，额外预留512MB以上给持久化子进程的copy-on-write内存
• 禁止设成maxmemory 90% of total RAM这类模糊表达——Redis不识别百分比，只认字节单位（2gb、1024mb、512000000）

配了maxmemory但淘汰没发生？检查这三处硬性条件

即使正确设置了maxmemory和maxmemory-policy，淘汰也可能静默失效。常见卡点不在策略本身，而在内存统计与触发时机。

• 淘汰只在**写命令执行过程中**检测内存超限（如SET、LPUSH），读命令（GET、HGETALL）不会触发；所以单纯dump数据看不出淘汰行为
• INFO stats中evicted_keys为0，但used_memory_human长期贴近maxmemory，说明淘汰被阻塞——大概率是maxmemory-policy noeviction（拼写错误或配置未重载）
• 使用allkeys-*策略时，若所有key都带过期时间（EXPIRE），Redis仍按全部key处理；但用volatile-*策略时，**没有过期时间的key完全免疫淘汰**，哪怕内存爆满也岿然不动

Redis的淘汰机制不是后台守护线程，它没有“定期扫描”或“预判式清理”。一切动作都绑在客户端命令的执行路径上，这意味着：压力低时淘汰延迟明显，突发写入可能瞬间冲破阈值导致写失败——这个反应滞后性，是很多容量评估翻车的真正盲区。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Redis无maxmemory配置会自动淘汰吗？》文章吧，也可关注golang学习网公众号了解相关技术文章。