Redis在K8s中被OOMKilled主因是maxmemory未显式配置或未与limits.memory匹配：需设为limits的70%–80%（如2Gi→1536mb），禁用noeviction，统一使用allkeys-lru等合理淘汰策略，并确保StatefulSet中resources.limits.memory与ConfigMap或env注入的maxmemory协同一致。
Redis在K8s里被OOMKilled，八成不是内存不够，而是maxmemory没设、设错了，或者淘汰策略选成了noeviction——它不释放内存，只报错，反而让客户端重试压垮缓冲区。
为什么maxmemory必须显式配置且不能等于limits.memory
Redis完全不感知cgroup限制，limits.memory: 2Gi对它毫无意义。它只认自己配置的maxmemory。设为0（默认）= 无限吃内存 → 触发内核OOM Killer；设成2gb = 忽略Redis自身开销（AOF rewrite缓冲、复制积压、连接buffer等）→ fork瞬间超限被杀。
-
maxmemory应设为limits.memory的70%–80%，例如limits.memory: 2Gi→maxmemory 1536mb（注意单位用小写mb/gb，2gb ≠ 2g） - StatefulSet中必须同时定义
resources.limits.memory和ConfigMap里的maxmemory，二者脱节就会出现部分Pod被杀、部分正常，集群行为不一致 - 若用Helm或Kustomize，避免硬编码；推荐通过env注入：
command: ["sh", "-c", "redis-server /etc/redis.conf --maxmemory $REDIS_MAXMEMORY"]
allkeys-lru比volatile-lru更适合大多数缓存场景
业务缓存往往不强制所有key都带过期时间，volatile-*类策略会跳过无TTL的key，导致内存持续上涨却无法淘汰——最终还是触发maxmemory满而noeviction生效（如果误配），或直接OOM。
-
allkeys-lru对所有key生效，适配二八访问规律，保留热点、淘汰冷数据，命中率稳定 -
volatile-ttl看似“智能”，实则容易误伤：一批key集中设置24h过期，但其中部分是高频读，ttl剩1分钟时就被删了 - 若业务确有大量临时key（如session、验证码），可考虑
volatile-lfu+ 合理maxmemory-samples 5提升淘汰精度，但需确认Redis ≥ 4.0
noeviction在K8s里是高危默认值，必须禁用
Redis 6.x及之前版本默认maxmemory-policy noeviction，意味着内存满后所有写操作返回(error) OOM command not allowed when used memory > 'maxmemory'。这不是优雅降级，而是把压力转嫁给上游——重试逻辑堆积请求、连接缓冲区暴涨、TCP backlog溢出，最终仍撞上容器limits.memory被OOMKilled。
- 生产环境禁止保留
noeviction，哪怕你用的是allkeys-lru，也建议显式写死，防止配置遗漏 - 验证是否生效：
redis-cli CONFIG GET maxmemory-policy输出必须是allkeys-lru之类，不能是noeviction - 集群模式下，所有Pod必须用同一份ConfigMap或统一
command参数，否则淘汰策略不一致会导致failover失败或数据倾斜
淘汰策略生效前，先确认used_memory_rss和碎片率
INFO memory里used_memory只是jemalloc统计的逻辑内存，真正占物理资源的是used_memory_rss。如果mem_fragmentation_ratio > 1.5，说明内存碎片严重，即使used_memory没到maxmemory，used_memory_rss也可能早已超限。
- 定期执行
redis-cli --bigkeys识别大key，它们是碎片和淘汰效率的隐形杀手 - 开启
activedefrag yes（Redis 4.0+）可后台自动整理，但会消耗CPU，需结合active-defrag-threshold-lower 10等参数控频 - 若碎片率长期>2.0，别只调淘汰策略——先查是否有未清理的死key、AOF重写是否卡住、或
lazyfree-lazy-eviction yes是否启用
真正难的不是选哪个策略，而是让maxmemory、淘汰策略、limits.memory、ulimits、tcp-backlog全部对齐——漏掉任意一环，穿透或OOM就可能在流量高峰时准时发生。
