Redis在K8s中缓存穿透需应用层防护+Redis兜底，因默认不限内存且K8s未设limits时，穿透会导致无效key激增、内存暴涨、OOMKilled；必须显式配置maxmemory（设为limits的70%～80%）、allkeys-lru策略、tcp-backlog与somaxconn同步、timeout=300及verbose日志等关键参数。
Redis 在 Kubernetes 中出现缓存穿透，不是靠改几个配置就能根治的；核心是应用层加防护 + Redis 层做兜底，容器化部署只是放大了配置不当带来的风险。
为什么 maxmemory 和 maxmemory-policy 必须显式配置
默认情况下 Redis 不限制内存使用，K8s 容器又没做 limits.memory，结果就是：缓存穿透触发大量无效 key 查询 → 应用层未拦截 → Redis 无差别加载空值或执行慢查询 → 内存持续上涨 → OOMKilled 或节点压力飙升。
必须在 ConfigMap 挂载的 redis.conf 里强制设置：
-
maxmemory设为容器limits.memory的 70%～80%，留出空间给 Redis 自身开销（如复制缓冲区、AOF rewrite） -
maxmemory-policy推荐allkeys-lru或volatile-lfu，避免用noeviction（默认值）——它会让写入直接失败，反而加剧上游重试风暴 - 如果业务允许，配合
maxmemory-samples 5提高淘汰精度，降低误删概率
容器内 ulimit -n 不生效？那是没配对地方
K8s Pod 启动后，ulimit -n 显示 1048576 是假象——这是宿主机的值，容器进程实际受 cgroup pids.max 和 fs.file-max 双重约束。Redis 日志里出现 WARNING overcommit_memory is set to 0! 或 OOM killer enabled，往往就卡在这儿。
真正有效的做法是两层联动：
- 宿主机执行
sysctl -w fs.file-max=2097152并写入/etc/sysctl.conf - K8s Pod
securityContext中加ulimits（需 runtime 支持）：securityContext: ulimits: - name: nofile soft: 65535 hard: 65535 - 同时在容器启动命令里显式传参：
redis-server /etc/redis/redis.conf --maxclients 20000，这个值不能超过 ulimit 软限制
tcp-backlog 和 timeout 配置不匹配会放大穿透冲击
当大量客户端因穿透反复建连又断开，net.core.somaxconn（宿主机）和 tcp-backlog（Redis 配置）不一致，会导致连接被内核丢弃，客户端重试倍增。
必须同步调优：
- 宿主机
sysctl -w net.core.somaxconn=65535 -
redis.conf中设tcp-backlog 65535（注意：该值不能超过somaxconn） -
timeout 300（秒）必须启用，否则空闲连接长期占着maxclients名额；但别设太小（如 30），否则健康检查或长轮询会被误杀 - 如果用了 Service Mesh（如 Istio），还要确认其 sidecar 的连接空闲超时 ≥ Redis 的
timeout
ConfigMap 挂载的 redis.conf 里最容易漏掉的三行
很多人只配 maxmemory，却忽略这三行，导致穿透时日志刷屏、指标失真、故障定位困难：
-
log-level verbose→ 穿透期间必须开，否则看不到Client closed connection或Rejected connection类警告 -
slowlog-log-slower-than 10000→ 把慢查询阈值从默认 10ms 放宽到 10ms，避免穿透引发的批量空 key 查询被误标为“慢” -
latency-monitor-threshold 0→ 关闭延迟监控（默认关闭），它在高并发下本身就会吃 CPU，穿透时雪上加霜
这些参数不起眼，但在穿透发生时，它们决定你是快速定位到空 key 扫描，还是盯着一堆无关慢日志干瞪眼。
