redlock续期不能靠expire简单重设，因其缺乏原子性与所有权校验：若锁已被其他客户端释放，expire会作用于不存在的key导致续期失败且无感知，甚至引发“幽灵锁”；必须用lua脚本封装get+pexpire并比对token，确保仅持锁者可续期。
Redlock 续期为什么不能靠 EXPIRE 简单重设？
Redis 官方 Redlock 算法要求锁必须具备“自动过期 + 主动续期”双保障，但直接对锁 key 执行 EXPIRE 会破坏原子性：如果客户端 A 续期时恰好锁被其他客户端 B 释放（比如因网络延迟导致锁已超时被删），EXPIRE 就会作用在不存在的 key 上，续期失败且无感知。更糟的是，B 可能已拿到新锁，A 还在续自己的“幽灵锁”。
- 续期操作必须和锁持有权校验绑定，即“只有当前持锁者才能续”
- 推荐用 Lua 脚本封装
GET+SET+EXPIRE逻辑，保证原子性 - 脚本中需比对 value（随机 token）是否匹配，不匹配直接返回失败，避免误续
Go 中实现安全续期函数的关键参数设计
续期函数不能只传入 client 和 key，必须显式携带 lock token 和新 TTL，否则无法验证所有权或控制续期窗口。
-
token：加锁时生成的唯一随机字符串（如uuid.NewString()），用于身份核验 -
ttlMs：新过期时间（毫秒），建议设为原 TTL 的 2/3，留出网络与执行缓冲 -
retryCount：续期失败后重试次数，避免单点 Redis 故障导致锁意外释放 - 不要复用加锁时的
ctx，续期应使用独立、带超时的新context.Context
示例核心逻辑：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
<pre class="brush:php;toolbar:false;">script := redis.NewScript(`
if redis.call("GET", KEYS[1]) == ARGV[1] then
return redis.call("PEXPIRE", KEYS[1], ARGV[2])
else
return 0
end
`)
result, err := script.Run(ctx, client, []string{key}, token, ttlMs).Int64()
Redlock 多节点场景下续期失败的降级策略
Redlock 要求多数节点续期成功才算续期有效。若某次续期只在 2/5 节点成功，剩余 3 个失败（网络抖动或节点宕机），此时锁实际已处于“部分失效”状态——继续执行业务可能引发冲突。
- 不建议静默忽略失败，应立即返回错误并触发业务层中断（如 panic 或返回
ErrLockExpired） - 可设置“最大连续续期失败次数”，比如连续 2 次失败就主动释放本地锁并退出临界区
- 避免在续期失败后仍尝试读写共享资源，这是分布式锁失效最典型的误用
- 监控指标必须包含
redlock_renew_fail_count和redlock_renew_quorum_miss
Go 客户端库对 Redlock 续期的支持现状
主流 Redis Go 客户端对 Redlock 续期支持参差不齐：github.com/go-redis/redis/v8 提供了 Lock 但无内置续期；github.com/bsm/redislock 支持自动后台续期，但默认启用且不可关闭，容易掩盖续期失败问题。
- 生产环境建议手写续期逻辑，而非依赖封装库的“自动续期”开关
- 若用
redislock，务必调用lock.Refresh()显式续期，并检查返回 error -
github.com/mediocregopher/radix/v4无 Redlock 实现，需自行组合redis.Cmdable构建 - 所有客户端都绕不开一个事实：续期不是“调一次就行”，它必须嵌入业务主循环，定期触发
真正麻烦的从来不是写几行 Lua，而是判断什么时候该停、什么时候该退、什么时候该报警——这些边界条件几乎不会出现在 demo 代码里。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
