一、前言
传统物理机 / 虚拟机部署模式下，服务实例 IP、运行节点相对固定。迁移到 K8s 之后，Pod 动态创建、销毁、漂移、扩缩容、IP 频繁变化成为常态，再加上容器网络、资源隔离、服务发现、探针检测等新特性，原本稳定运行的分布式锁会暴露出全新问题：锁归属识别异常、续期中断、死锁残留、扩缩容瞬间并发击穿等。 本篇从场景痛点入手，逐一给出适配方案、代码改造、K8s 配置、Redis 调优，形成容器环境专属的分布式锁落地标准。
二、云原生环境核心新痛点梳理
2.1 Pod 漂移与重建导致锁异常
K8s 因节点宕机、资源不足、调度策略、滚动更新等原因，会将 Pod 从一个节点调度到另一节点，或是直接重建 Pod。
- 正常重建：旧 Pod 进程终止，看门狗续期线程停止，锁依靠过期时间自动释放，风险较低；
- 强制驱逐 / 内核卡死 ：Pod 被强行杀死，进程无退出逻辑，Redis 锁长期滞留，形成临时死锁；
- 短时间重复创建：旧锁未过期，新 Pod 启动后竞争锁失败，业务短暂不可用。
2.2 容器 IP 动态变化，线程标识失效
传统实现常用「服务 IP + 线程 ID」作为锁持有者标识，容器环境下 Pod IP 每次重建都会改变：
- 旧 Pod 残留锁的标识为旧 IP，新 Pod 无法识别、无法主动解锁；
- 运维人员无法通过 IP 定位异常锁归属实例，排查难度加大。
2.3 动态扩缩容引发并发突增
流量高峰触发 HPA 自动扩容，瞬间新增大量 Pod，大量实例同时竞争锁：
- 锁等待队列暴涨，接口超时率上升；
- Redis 锁相关命令 QPS 突增，Redis 压力变大；
- 公平锁排队过长，业务响应延迟加剧。
2.4 容器网络与链路超时问题
容器网络多了多层转发（宿主机网桥、Service、Ingress），网络延迟、丢包概率高于物理机：
- 看门狗定时续期请求超时，锁被提前释放；
- 加锁 / 解锁 Lua 脚本执行超时，出现加锁成功但返回失败的假象；
- 跨命名空间、跨集群访问 Redis，网络抖动进一步放大锁异常。
2.5 健康探针误杀进程
K8s 存活探针、就绪探针超时，会主动重启 Pod。若此时线程正持有锁执行业务，直接中断运行，锁残留风险提升。