Golang分布式锁实现详解：从单机到Redis、ZooKeeper及Etcd方案对比

为什么需要锁：并发修改的风险

在程序中，当多个 goroutine 并行或并发地修改同一个全局变量时，若无同步机制保护，会产生数据竞争（Data Race），导致结果不可预测。

以下代码演示了未加锁时的典型问题：

package main

import (
	"sync"
)

var counter int

func main() {
	var wg sync.WaitGroup
	for i := 0; i < 1000; i++ {
		wg.Add(1)
		go func() {
			defer wg.Done()
			counter++
		}()
	}
	wg.Wait()
	println(counter) // 运行结果往往小于1000
}

多次执行上述代码，输出结果通常在900-999之间波动，因为 `counter++` 并非原子操作，涉及读取、自增、写回三个步骤，易被其他协程打断。

进程内加锁：sync.Mutex的应用

对于单机单进程内的并发控制，使用标准库 sync.Mutex 是最简单且高效的方式。它将临界区代码包裹起来，确保同一时刻只有一个 goroutine 能执行。

// ... 省略部分代码
var l sync.Mutex
for i := 0; i < 1000; i++ {
    wg.Add(1)
    go func() {
        defer wg.Done()
        l.Lock()          // 加锁
        counter++         // 临界区
        l.Unlock()        // 解锁
    }()
}
// ... 省略部分代码

加锁后，程序每次运行都能稳定输出 1000，证明了临界区保护的必要性。

TryLock与非阻塞争抢

某些场景下，如果获取锁失败，我们希望立即返回而非无限等待。可以通过 Channel 实现一个简单的 TryLock。

type Lock struct {
    c chan struct{}
}

func NewLock() Lock {
    var l Lock
    l.c = make(chan struct{}, 1)
    l.c <- struct{}{}
    return l
}

func (l Lock) Lock() bool {
    lockResult := false
    select {
    case <-l.c:
        lockResult = true
    default:
    }
    return lockResult
}

func (l Lock) Unlock() {
    l.c <- struct{}{}
}

这种实现利用了缓冲 Channel 的非阻塞特性。若 Channel 中有信号，则获取成功；否则直接返回 False。需要注意的是，在单机高并发场景下频繁调用此方法可能导致 CPU 空转，形成“活锁”现象，因此它更适用于简单的防重入判断，而非复杂的并发控制。

基于Redis SetNX的分布式锁

当服务部署在多台机器上时，进程内锁失效，需借助外部存储如 Redis 实现分布式锁。Redis 的 SETNX (SET if Not eXists) 命令配合过期时间（PX），是实现分布式锁的基础。

第1步：连接Redis客户端

引入 github.com/go-redis/redis 包建立连接，配置地址、密码及DB号。

第2步：尝试获取锁

使用 SetNX 命令设置唯一的 Lock Key。关键参数包括：
- Key：锁的唯一标识
- Value：任意值
- Expire：超时时间，防止死锁（如持有锁的服务宕机）

client := redis.NewClient(&redis.Options{
    Addr:     "localhost:6379",
    DB:       0,
})
lockKey := "counter_lock"
resp := client.SetNX(lockKey, 1, time.Second*5)
lockSuccess, err := resp.Result()
if err != nil || !lockSuccess {
    // 获取锁失败，处理逻辑
    return
}

第3步：执行业务逻辑

仅在 lockSuccess 为 True 时，继续执行受保护的代码（如计数器递增）。此阶段应保证逻辑尽量短小，避免长时间持有锁导致其他节点阻塞。

第4步：释放锁

使用 DLL 或 Del 命令删除 Key。**注意**：生产环境中建议使用 Lua 脚本校验 Value 是否正确再删除，以防误删其他实例生成的锁。本例为简化展示直接删除。

delResp := client.Del(lockKey)
unlockSuccess, _ := delResp.Result()
if unlockSuccess > 0 {
    println("unlock success!")
}

适用场景：Redis 锁适合高并发下的“唯一资源”争抢，如订单生成、秒杀库存扣减。其优势在于高性能和广泛的社区支持，但缺点是弱一致性（单点故障或网络分区可能导致锁失效）。

基于ZooKeeper的分布式锁

ZooKeeper 提供了强一致性保证，其锁机制依赖于 临时顺序节点（EPHEMERAL_SEQUENTIAL） 和 Watcher 机制。

实现原理

1. 创建临时顺序子节点：请求方在指定父节点（如 /lock）下创建自己的临时顺序节点。
2. 获取子节点列表：检查该父节点下所有子节点的序列号。
3. 判断最小值：如果创建的节点是序列号最小的节点，则视为获得锁。
4. 监听前一个节点：如果不是最小节点，则监听紧随其后的那个节点的删除事件。当前一个节点被删除（即前一位持有者释放锁）时，当前节点重新参与竞争。

代码示例

c, _, err := zk.Connect([]string{"127.0.0.1"}, time.Second * 5)
l := zk.NewLock(c, "/lock", zk.WorldACL(zk.PermAll))
err = l.Lock()
if err != nil { panic(err) }
// 执行业务逻辑
time.Sleep(time.Second * 10)
l.Unlock()

特点：ZK 锁是阻塞式的。类似于单机 Mutex，调用 Lock() 后会挂起直到获得锁。这避免了 CPU 空转，但在高频短时间的锁竞争中，频繁的 Watcher 触发和网络开销会带来较高延迟。适合对可靠性要求极高、持锁时间较长的粗粒度场景（如分布式任务调度）。

基于Etcd的分布式锁

Etcd 同样提供强一致性 KV 存储，其分布式锁实现依赖 Lease（租约）和 Key 的生命周期管理，流程略有不同：

1. 检查存在性：尝试获取 Key 的值。如果 Key 已存在，说明锁被占用。
2. 写入/比较：尝试 PUT 自己的值到 Key。Etcd 支持条件更新，可设置 CreateRevision 或 ModRevision 确保只在自己创建的 Key 上才能删除/续租。
3. 阻塞监听：如果写入失败或 Key 已被他人占有，启动 Watch 监听该 Key 的变化。
4. 唤醒重试：收到删除或版本更新通知时，循环重试第一步。

代码示例

m, err := etcdsync.New("/lock", 10, []string{"http://127.0.0.1:2379"})
err = m.Lock()
// ... 执行业务 ...
m.Unlock()

适用场景：与 ZK 类似，适合高一致性要求的场景。Etcd 在现代 Kubernetes 生态中更为常见，运维团队通常更熟悉。相比 ZK，Etcd 在某些高并发写入压力下的表现更具优势，但其锁机制仍需 careful 设计以防止“惊群效应”（大量 Waiters 同时苏醒造成的瞬间负载高峰）。

Redlock：Redis 的多节点容错方案

由于单一 Redis 节点存在宕机导致锁丢失的风险，Redis 作者提出 Redlock 算法，旨在利用多节点提升可用性。

核心逻辑

Redlock 并不直接在 Redis 集群上使用，而是假设拥有 N 个完全独立（甚至异地部署）的 Redis 主节点。客户端依次向 N 个节点申请锁，如果能在 T 时间内从超过半数（N/2 + 1）节点成功获取锁，则认为整体加锁成功。

pools := newPools([]string{"127.0.0.1:6379", "127.0.0.1:6378", "127.0.0.1:6377"})
rs := redsync.New(pools)
m := rs.NewMutex("my_resource")
err := m.Lock()
// ... 业务 ... 
m.Unlock()

争议与现状：Redlock 自诞生起便伴随争议。部分学者指出在网络分区时钟漂移等极端条件下，Redlock 仍可能失效。尽管工程实践中广泛使用，但在架构设计初期，应充分评估其复杂性（需维护多组独立 Redis 实例）与收益。若仅为了高可用，许多场景下直接使用有副本的 Redis Sentinel 或 Cluster 模式可能更简单可靠。

如何选择分布式锁方案

注意事项：

• 运维成本：ZK 和 Etcd 集群扩展能力有限，无法像 NoSQL 那样随意横向扩容。增加节点主要提高冗余度而非吞吐。大规模下可能需要分片多个集群，增加路由复杂度。
• 时钟容忍：所有基于 Token/TTL 的锁（Redis, Etcd）都依赖系统时钟。确保服务器时间同步（NTP），避免锁提前过期或永久不释放。
• 锁的粒度：尽量避免长事务持有锁。长持有会阻碍整个系统的并发能力。

综上所述，没有绝对完美的分布式锁，只有最适合当前业务形态的技术选型。在代码落地前，务必进行充分的压测与异常模拟，确保在节点故障、网络抖动等异常情况下的系统韧性。

以上就是关于Golang分布式锁实现的详细内容，更多关于Go分布式锁选型的资料请关注本站其它相关文章！