必须同时设置maxmemory和maxmemory-policy；仅设maxmemory时redis不触发淘汰，used_memory_rss持续增长直至被oom killer杀死。
必须同时设置 maxmemory 和 maxmemory-policy，缺一不可；只设 maxmemory 而策略拼错、大小写混用或留空，默认行为不生效，Redis 仍会吃光内存被系统 OOM Killer 杀掉。
为什么只配 maxmemory 还会被 OOM Kill
Redis 的 maxmemory 不是“内存保险丝”，它只在淘汰策略启用时才参与水位判断。没配 maxmemory-policy，或配了但写成 no-eviction、NoEviction、noeviction （末尾空格），Redis 会退回到默认策略——高版本虽默认 noeviction，但不显式声明就等于把控制权交给版本和运气。
更危险的是：maxmemory 2gb 单独存在时，Redis 实际上不会拒绝写入，而是持续接收数据，直到 used_memory_rss 触达系统或容器的物理上限，触发内核 OOM Killer 直接干掉进程。
- 验证方式：执行
redis-cli CONFIG GET maxmemory-policy，必须返回noeviction（全小写、无空格） - 若
INFO memory中evicted_keys持续增长，说明策略根本不是noeviction -
used_memory看的是 Redis 数据层占用，而 OOM Killer 杀的是used_memory_rss（含碎片、AOF 缓冲、复制积压等）
maxmemory 应该设多大才安全
不能拍脑袋填 maxmemory 80% 或 maxmemory 16gb —— Redis 不支持百分比语法，且设满物理内存极大概率翻车。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 推荐值：总内存的 60%–70%，并预留 15%–20% 给碎片、AOF rewrite、复制缓冲区和 Lua 脚本栈。例如 16GB 机器，设
maxmemory 12gb比14gb更稳妥 - Kubernetes 场景下，
maxmemory必须小于resources.limits.memory，建议为后者的 70%–80%（如 limits:2Gi→maxmemory 1536mb） - 单位必须明确：只认
kb/mb/gb（小写），2g或2GB无效 - 实测中，
maxmemory 1gb对应的used_memory_rss常达 1.2–1.4gb，尤其在 RDB fork 或 AOF rewrite 高频写入时会发生 COW 翻倍
怎么让 maxmemory 配置真正生效不丢失
CONFIG SET 只影响当前运行实例，重启即失效。生产环境必须落盘。
- 编辑
redis.conf，添加两行（位置不限，建议放在 MEMORY LIMIT 区块）：maxmemory 12gbmaxmemory-policy allkeys-lru - 执行
redis-cli CONFIG REWRITE—— 它会自动重写配置文件，保留注释和结构，比手动改更安全 - 不要直接
kill -9后重启；先redis-cli SHUTDOWN SAVE，再启 - 重启后立刻验证：
redis-cli CONFIG GET maxmemory和CONFIG GET maxmemory-policy -
CONFIG REWRITE不会覆盖你手动加的注释，但会删掉语法错误或无效配置行，改完务必检查
选 noeviction 还是 allkeys-lru？关键看业务容忍度
noeviction 不是“最安全”的选项，而是“最激进的拒绝”。它会让所有写命令失败并返回 (error) OOM command not allowed when used memory > 'maxmemory' —— 这不是网络异常，是 Redis 主动拒写。
- 适用场景：数据绝对不能丢（如金融核心配置），且有配套监控+人工干预流程
- 风险点：某些客户端 SDK 在 pipeline 中批量写入时，可能让 Redis 误判访问时间戳，造成“刚写入就淘汰”；而
noeviction下这类请求直接失败，还可能因重试逻辑堆积缓冲区，间接推高 RSS - 缓存类业务推荐
allkeys-lru，但注意它不区分 key 类型——长期存在的白名单 key 和临时缓存 key 会被一视同仁淘汰；若大量 key 无 TTL，volatile-lru就完全失效 - 验证回收是否合理：别只盯
evicted_keys，要用MEMORY USAGE <key></key>和OBJECT IDLETIME <key></key>抽查典型 key，再结合keyspace_hits/keyspace_misses推断淘汰倾向
最容易被忽略的一点：无论你设得多精细，只要 maxmemory 和 maxmemory-policy 没同时落盘、没验证过返回值、没盯紧 used_memory_rss，OOM Killer 就随时可能动手——它不看文档，只看 RSS。
