分布式锁的可用性取决于独立高可用redis集群与redlock客户端的正确配置，而非应用多实例部署；需用statefulset部署redis、go客户端初始化至少3个独立redis.client、设置合理超时与重试、确保节点时钟同步。
多实例部署本身不解决分布式锁的可用性问题，关键在于锁后端（如 Redis）的拓扑与客户端访问方式是否适配集群调度模型。
Redis 实例必须跨节点部署，不能共用单 Pod
常见错误是把 Redis 也打包进同一个 Deployment，导致所有 Go 实例连的是本地 Redis 副本——这根本不是分布式锁，只是多个本地锁。真正生效的锁服务必须由独立、高可用的 Redis 集群提供。
- 用 StatefulSet + headless Service 部署 Redis 主从或 Redis Cluster，确保每个 Pod 有稳定网络标识和独立存储
- 禁止在 Go 应用容器里启动 redis-server 或用 docker-compose up -d 模拟“多实例”——Kubernetes 不认这种拓扑
- 若用云托管 Redis（如 AWS ElastiCache、阿里云 Tair），确认 endpoint 是全局可访问的，且网络策略允许 Go Pod 出向连接
Go 客户端必须用 Redlock 而非单点 SETNX
单 Redis 实例故障会导致整个锁服务不可用；Redlock 通过多数派节点达成共识，容忍部分实例宕机。但它的实现对时间精度敏感，在 Kubernetes 环境下容易因节点时钟漂移失败。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 使用
github.com/go-redsync/redsync/v4，初始化时传入至少 3 个独立*redis.Client实例（对应不同 Redis 节点） - 设置
WithExpiry(10 * time.Second)和WithTries(3)，避免因短暂网络抖动重试过多 - 务必调用
mutex.Unlock()—— Kubernetes 下 goroutine 泄漏比进程崩溃更隐蔽，不释放锁会快速耗尽 Redlock 的尝试配额 - 不要自己拼接
SET key value NX PX：Redis 6.2+ 的SET命令支持原子性过期+值校验，但 Redlock 库已封装兼容逻辑
Kubernetes DNS 与服务发现不影响锁通信，但影响配置注入
分布式锁的 Redis 连接地址不是通过 Kubernetes Service DNS 解析的，而是由 Go 应用直接读取 ConfigMap/Secret 中的 REDIS_ADDRS 字符串列表。DNS 失效不会中断锁，但配置加载失败会直接 panic。
- 把 Redis 地址列表写进 ConfigMap，格式为
redis://10.244.1.5:6379,redis://10.244.2.8:6379,redis://10.244.3.12:6379 - Go 启动时解析该字符串，用
redis.NewClusterClient或循环创建多个redis.NewClient - 避免用
envFrom直接注入环境变量再os.Getenv("REDIS_ADDRS")—— 若 ConfigMap 更新，正在运行的 Pod 不会自动 reload，必须重启或监听变更 - 加一层 fallback：若 ConfigMap 为空，尝试读取
/etc/redis/fallback.conf（通过 downwardAPI 或 initContainer 注入）
资源限制与探针必须匹配锁操作耗时
Redlock 获取锁要串行访问多个 Redis 节点，一次完整流程可能耗时 100–300ms。若 livenessProbe 超时设为 1s 且失败阈值为 3 次，网络抖动就可能触发误杀。
- readinessProbe 的
initialDelaySeconds至少设为 10，等 Redlock 客户端完成首次健康检查 - livenessProbe 使用独立路径（如
/healthz/lock），内部执行一次mutex.Lock()+Unlock()，超时设为 5s - 给容器设
resources.limits.memory: "512Mi"—— Redlock 持有随机字符串和时间戳，内存暴涨通常意味着锁未释放或 goroutine 卡死 - 禁止在锁临界区内做 HTTP 调用或数据库查询：Kubernetes 的网络延迟波动会让锁持有时间不可控，直接违反 Redlock 的时间约束假设
最容易被忽略的是时钟同步：Kubernetes 节点若未启用 NTP 或 chrony，Redlock 的 T2 - T1 计算会失真，导致锁被提前判定为失效。上线前必须确认所有 Node 执行 timedatectl status | grep "System clock synchronized" 返回 yes。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
