在微服务架构中，分布式锁是解决“并发抢占资源”（例如秒杀扣库存、防重复提交等）的关键工具。很多开发者认为用 Redis 实现分布式锁不过是一行 SETNX 的事情。但实际上，从“能跑的玩具代码”到“生产级的高可用组件”，中间隐藏着无数个暗坑。

今天，我们重新审视 Redis 分布式锁。不仅要填平那 5 个著名的“血坑”，还要融入 Go 语言特有的并发哲学（如 context 控制、Goroutine 泄漏防范、无 Goroutine ID 的可重入锁设计），最后甚至要探讨分布式系统泰斗 Martin Kleppmann 对 Redis 锁的灵魂拷问。

准备好了吗？出发！

演进一：基础实现与原子性陷阱 (The Basics)

新手的做法：先 SetNX，再 Expire。中间如果程序崩溃（OOM 或重启），锁永远无法释放，直接导致死锁。

进阶的做法：使用 SET key value NX EX time 原子命令。但在 Go 的工程实践中，绝不能写面条代码。一位中高级的 Go 开发者，首先想到的是封装与面向对象设计。我们会使用 Go 经典的 Functional Options 模式来构建锁对象。

package redislockimport ("context""crypto/rand""encoding/hex""errors""time""github.com/redis/go-redis/v9")var ErrLockFailed = errors.New("failed to acquire lock")// Client 抽象 Redis 客户端，方便 mock 测试type Client interface { SetNX(ctx context.Context, key string, value interface{ }, expiration time.Duration) *redis.BoolCmdEval(ctx context.Context, script string, keys []string, args ...interface{ }) *redis.Cmd}type Options struct { Expiration time.DurationRetryWaittime.DurationMaxRetries int}type Option func(*Options)// RedisLock 生产级分布式锁结构体type RedisLock struct { client Clientkeystringtokenstring // 锁的唯一标识，防误删opts Options}// NewRedisLock 构造函数func NewRedisLock(client Client, key string, optFuncs ...Option) *RedisLock { opts := Options{ Expiration: 30 * time.Second,RetryWait:50 * time.Millisecond,MaxRetries: 3,}for _, f := range optFuncs { f(&opts)}return &RedisLock{ client: client,key:key,token:generateToken(), // 生成唯一 Tokenopts: opts,}}// generateToken 生成 16 字节的随机 hex 字符串func generateToken() string { b := make([]byte, 16)rand.Read(b)return hex.EncodeToString(b)}

演进二：安全解锁与 Lua 脚本 (Safe Unlock)

踩坑点：协程 A 的锁超时后，协程 B 抢到了锁。协程 A 此时跑完业务，执行 DEL key，把协程 B 的锁删了，导致系统雪崩。

专家解法：解锁时必须校验 token，且“判断 + 删除”必须是原子操作。在 Go 中，通常会将 Lua 脚本预加载（SCRIPT LOAD）或者直接使用 Eval。

const unlockScript = `if redis.call("get", KEYS[1]) == ARGV[1] thenreturn redis.call("del", KEYS[1])elsereturn 0end`// Unlock 安全解锁func (l *RedisLock) Unlock(ctx context.Context) error { res, err := l.client.Eval(ctx, unlockScript, []string{ l.key}, l.token).Result()if err != nil { return err}if n, ok := res.(int64); !ok || n == 0 { return errors.New("unlock failed: lock not held by this token")}return nil}

演进三：锁超时与看门狗机制 (Watchdog)

踩坑点：锁 TTL 设为 30 秒，但业务遇到慢查询跑了 40 秒。第 30 秒时锁自动失效，并发冲突随之产生。

专家解法：引入 Watchdog（看门狗）后台协程自动续期。作为中高级 Go 开发者，编写后台 Goroutine 时必须考虑生命周期管理和防 Goroutine 泄漏。千万不能直接 go func() { for {} }()。必须结合 context 和 chan 实现优雅退出。

// 续期 Lua 脚本const renewScript = `if redis.call("get", KEYS[1]) == ARGV[1] thenreturn redis.call("pexpire", KEYS[1], ARGV[2])elsereturn 0end`// startWatchdog 启动看门狗func (l *RedisLock) startWatchdog(ctx context.Context, done chan struct{ }) { // 续期周期通常为超时时间的 1/3ticker := time.NewTicker(l.opts.Expiration / 3)defer ticker.Stop()for { select { case <-ticker.C:// 执行续期res, err := l.client.Eval(ctx, renewScript, []string{ l.key}, l.token, int64(l.opts.Expiration/time.Millisecond)).Result()// 如果锁已经被释放（返回0），或者发生错误，看门狗退出if err != nil || res.(int64) == 0 { return }case <-done:// 业务主动解锁，通知看门狗退出returncase <-ctx.Done():// 父 Context 取消，看门狗退出return}}}

注意这里的 select 监听了 ctx.Done()，这是生产级代码的标配。如果整个 HTTP 请求被用户 abort，业务 Context 会被 cancel，看门狗必须能够感知并安全退出，防止 Goroutine 泄漏。

演进四：Go 语言中的“可重入锁”悖论

踩坑点：方法 A 拿到了锁，内部调用方法 B，方法 B 也去获取同一把锁，导致自己把自己死锁。

专家解法：在 Java 中，可重入锁实现很简单，因为 Java 有 ThreadLocal 和 ThreadID。但在 Go 中，Goroutine 没有暴露的 ID！很多新手尝试用汇编去 Hack 获取 Goroutine ID，这在工程上是极度危险且不被官方推荐的。

在 Go 中实现可重入锁，通常有两种高级姿势：

• Token 传递法：将加锁返回的 token 传递给下游函数，下游函数凭此 token 证明自己是“同一调用链”。
• Context 传递法（推荐）：将锁的标识存入 context.Context，在调用链中透传。

如果一定要在 Redis 层面做重入（参考 Redisson 做法），需要使用 Redis 的 Hash 结构：Key 是锁的名称，Field 是唯一的协程标识（可以用 uuid 或链路追踪 TraceID），Value 是重入次数。

-- 可重入加锁 Lua 脚本local key = KEYS[1]local thread_id = ARGV[1]local ttl = ARGV[2]if (redis.call('exists', key) == 0) thenredis.call('hset', key, thread_id, 1)redis.call('pexpire', key, ttl)return 1endif (redis.call('hexists', key, thread_id) == 1) thenredis.call('hincrby', key, thread_id, 1)redis.call('pexpire', key, ttl)return 1endreturn 0

演进五：终极拷问 —— 主从切换与 Fencing Token

上面所有的努力，在单机 Redis 上已经无懈可击了。但生产环境全是 Redis Cluster 或主从哨兵架构。

终极坑点：Master 节点挂掉，异步复制导致锁没同步到 Slave。新 Master 上任，锁丢失，导致两个协程同时拿到锁！很多人会说：“用 Redlock（红锁）啊！”

但分布式系统专家 Martin Kleppmann 曾撰文狠狠批判过 Redlock。因为 Redlock 严重依赖服务器时钟同步。如果某台 Redis 服务器发生时钟跳跃（Clock Jump），或者进程发生了长时间的 GC Pause，Redlock 依然会崩溃。

终极专家的破局之道：

对于要求绝对强一致性的金融级场景，专家的选择是：

• 换掉 Redis：使用基于 Raft 协议、CP 模型的 etcd 或 ZooKeeper。etcd 的 Lease（租约）和 Watch 机制天生就是为分布式协调而设计的。
• 引入 Fencing Token（击剑令牌）：无论锁多么完美，我们都不信任它。在获取锁的同时，从发号器获取一个单调递增的 Token。当协程带着数据去操作数据库（或下游系统）时，必须带上这个 Token。下游系统通过乐观锁或唯一索引拒绝低版本 Token 的请求。

(Martin Kleppmann 提出的 Fencing Token 机制，是解决分布式锁超时/失效的最终防御底线)

总结与选型建议

从写下一行 SetNX 到构建一个生产级的分布式锁，体现的是一个 Go 开发者对系统边界的敬畏：

• 基础：原子操作（SetNX EX）与 Lua 脚本是底线。
• 健壮：用 context 控制超时，用 Watchdog 防止提前释放，坚决杜绝 Goroutine 泄漏。
• 架构：明白 Go 并发模型的特殊性（无 GID），通过 Context 传递上下文实现重入。
• 视野：跳出 Redis 的局限，理解 AP 模型与 CP 模型的差异。

技术选型建议：

• 常规业务（如限制用户操作频率、普通电商扣库存）：用 Redis 锁足够，建议直接使用开源库 go-redsync/redsync。
• 核心资金链路（如账务结算）：老老实实上 etcd，并配合数据库的乐观锁（版本号机制）进行兜底。