maxmemory 在容器中大概率失效是因为它仅是 Redis 内部逻辑限制，而容器实际受 cgroup memory limit 约束；当 fork 子进程时若 RSS 接近 cgroup 限，内核 OOM Killer 会直接杀进程，导致 RDB/AOF 失败。
为什么直接设 maxmemory 在容器里大概率失效
云原生环境（K8s + containerd）下，maxmemory 配置本身不会被容器 runtime 识别或强制约束。它只是 Redis 进程内部的逻辑上限，而真正起作用的是宿主机的 cgroup memory limit。当 Redis 的 used_memory_rss 接近 cgroup 限制时，内核会触发 OOM Killer —— 此时 Redis 还没来得及执行淘汰，进程就被干掉了。
常见错误现象：Fork operation failed: Cannot allocate memory，或者日志里反复出现 OOM command not allowed when used memory > 'maxmemory'，但 INFO memory 显示 used_memory 远低于 maxmemory。这说明问题不在 Redis 自身内存使用，而在 fork 子进程（RDB/AOF rewrite）时，操作系统无法分配足够物理内存。
-
maxmemory必须显著小于容器的 cgroup memory limit（建议 ≤ 70%） - 必须显式配置
maxmemory-reserved（Redis 6.0+），否则 fork 无缓冲空间 -
vm.overcommit_memory宿主机参数必须为 0 或 1；设为 2 时maxmemory-reserved被忽略
怎样用 CONFIG SET 动态调 maxmemory 而不重启
在集群滚动发布或突发流量期间，硬编码 redis.conf 不够灵活。推荐用 CONFIG SET 实时调整，但要注意：它只影响当前实例，且不持久化。
实操要点：
- 先查当前值：
redis-cli CONFIG GET maxmemory - 设新值（单位支持
mb、gb）：redis-cli CONFIG SET maxmemory 1536mb - 必须同步设淘汰策略：
redis-cli CONFIG SET maxmemory-policy allkeys-lru，否则默认是noeviction，写入直接报错 - 调完立刻验证：
redis-cli INFO memory | grep -E "(used_memory_human|maxmemory|mem_fragmentation_ratio)"，重点看mem_fragmentation_ratio是否突增（> 1.5 表示碎片严重，可能影响实际可用空间）
自动化调整的关键不是“动态”，而是“有依据”
盲目按 CPU 或 QPS 调 maxmemory 没意义。真正该盯住的指标只有两个：used_memory_rss 和 mem_fragmentation_ratio，它们来自 INFO memory。
自动化脚本逻辑应围绕以下判断链：
- 如果
used_memory_rss/ 容器 memory limit > 0.75 → 触发降级：减小maxmemory并检查是否有大 key（redis-cli --bigkeys） - 如果
mem_fragmentation_ratio> 1.6 → 不是调maxmemory，而是该redis-cli CONFIG SET activedefrag yes开启主动碎片整理 - 如果
used_memory_rss稳定在 limit 的 40%~60%，但used_memory却很低 → 很可能是used_memory_overhead占比过高（比如大量小 key + 过期时间），这时该优化数据结构，而不是加内存
maxmemory-reserved 是云原生环境下最容易漏掉的一环
这个参数不参与淘汰，也不影响 used_memory 统计，但它决定了 fork 能否成功。在容器里，它的缺失比 maxmemory 设错更致命。
正确做法：
- 值 = 估算 fork 开销，通常取
used_memory_rss * 0.1 ~ 0.2，最低不少于 128MB（134217728） - 必须用字节单位设置，不支持后缀：
redis-cli CONFIG SET maxmemory-reserved 268435456 - 检查是否生效：
redis-cli INFO memory | grep mem_not_counted_for_evict，该字段非零才表示预留成功 - 若用 Helm 部署 Redis，需在
values.yaml中显式注入该参数，不能依赖默认值 0
复杂点在于：这个值没法一劳永逸。当业务写入模式突变（比如从缓存变成消息队列），fork 压力会线性上升，必须和 used_memory_rss 监控联动做周期性重算。
