Go 分布式锁设计与实现：Redis Redlock、etcd 与幂等性保证

Go 分布式锁设计与实现：Redis Redlock、etcd 与幂等性保证

在单体应用中，我们通过 sync.Mutex 或 sync.RWMutex 来保护临界区，确保同一时间只有一个 goroutine 访问共享资源。但当应用从单体架构演进为分布式微服务架构时，这些本地锁失去了效力——多个实例运行在不同的节点上，它们的内存空间是隔离的，没有任何一个进程能够感知其他进程中的锁状态。此时，分布式锁成为协调跨进程、跨机器资源的唯一手段。

然而，分布式锁远非 “在 Redis 里 set 一个 key” 这么简单。要实现一个真正可靠的分布式锁，需要处理锁的获取、续期、释放，应对网络分区、节点故障、时钟漂移等复杂问题。同时，分布式锁与业务的幂等性设计是相辅相成的——锁用于串行化竞争操作，幂等性确保即使锁失效也不会造成不可挽回的数据不一致。

本文将深入剖析 Redis（含 Redlock 算法）、etcd、ZooKeeper 以及数据库乐观锁四种主流分布式锁方案，并给出完整的 Go 语言实现代码。我们将从理论基础出发，一步步推导每一行代码背后的设计考量，帮助你在生产环境中做出正确的技术选型。

为什么需要分布式锁

让我们先看一个典型的真实场景。

一个经典的超卖问题

你负责维护一个电商平台的秒杀系统。某款热门商品库存只有 100 件，活动开始时吸引了几万人的抢购请求。系统后端的处理逻辑大致如下（伪代码）：

1. 查询数据库：SELECT stock FROM products WHERE id = 1;    // 返回 100
2. 判断 stock > 0
3. 扣减库存：UPDATE products SET stock = stock - 1 WHERE id = 1;
4. 创建订单

在单线程环境下，这个逻辑完全正确。但在高并发的分布式环境中，如果没有任何并发控制，两个请求可能同时执行第 1 步，都读到 stock = 100，然后都执行第 3 步将库存变为 99。原本应该售出 2 件商品，结果实际只少了 1 件库存——更极端情况下，100 件库存可能卖出几百件，造成超卖。

这就是竞态条件（Race Condition）：多个并发单元的执行结果依赖于它们之间不可控的相对时序。单机环境下，sync.Mutex 可以完美解决。但在分布式场景中：

• 多个应用实例部署在不同的服务器上，操作系统层面的锁无法跨越进程边界。
• 即使是数据库自身的事务隔离级别，普通 READ COMMITTED 同样存在上述问题。

分布式锁的核心目的：在分布式系统中，当多个进程争夺共享资源时，确保同一时间只有一个进程获得排他性访问权。

不适合使用分布式锁的场景

分布式锁是有代价的：它引入了网络通信延迟、存在单点故障风险、需要处理复杂的超时逻辑。在以下场景中，应当考虑替代方案而非分布式锁：

1. 数据天然支持幂等更新：如果业务可以通过数据库的 UPDATE ... WHERE version = ? 或 UPDATE ... WHERE stock >= quantity 这类原子操作完成，数据库的乐观锁或条件更新往往更高效。
2. 无状态计算：不涉及共享资源状态变更的纯计算任务，天然无需锁。
3. 可以接受最终一致性：如果最终一致性即可满足业务需求，可以考虑基于消息队列的异步串行化，而非实时加锁。

分布式锁的基本要求：互斥、防死锁与容错

一个合格的分布式锁实现必须满足三个基本性质。它们像三根支柱，撑起了分布式锁的可靠性。

互斥性（Mutual Exclusion）

在同一时刻，只有一个客户端（进程/实例）能够获得锁。这是锁的定义本身，也是最容易理解的性质。实现互斥性的本质是在一个所有客户端都能访问的外部协调服务中，设置一个代表"锁已被持有"的标记，且"设置标记"这个操作本身是原子的。

不同的锁方案在"标记"的形式上有所不同：

• Redis 锁：一个带有过期时间的 key
• etcd 锁：一个以租约为生命周期的 key
• ZooKeeper 锁：一个临时顺序节点
• 数据库锁：FOR UPDATE 行锁或条件更新

防死锁（Deadlock Prevention）

如果一个客户端获取锁之后崩溃（例如服务被 OOM Kill 或进程被强制终止），它所持有的锁必须能够被自动释放，否则锁将永久处于被占用状态，其他客户端永远无法获取。

防死锁的经典方案是锁自动过期。每个锁都设置一个 TTL（Time To Live），即使客户端没有主动释放锁，锁也会在 TTL 结束后自动失效。代价是：如果 TTL 设置不合理（例如业务执行时间超过 TTL），锁可能在业务执行期间被错误释放，导致互斥性被破坏。这是分布式锁设计中最核心的矛盾之一，后续的锁续期（Watchdog）机制正是为了解决这一问题。

容错性（Fault Tolerance）

分布式锁的存储介质——无论是 Redis、etcd、ZooKeeper 还是数据库——本身也必须具备高可用性。如果锁存储节点是单点，一旦宕机，整个系统的锁机制就会瘫痪。

生产环境中，所有锁方案都要求协调服务以集群形式部署：

• Redis 采用主从复制或 Sentinel 模式或 Cluster 模式
• etcd 天然是强一致的分布式 KV 存储
• ZooKeeper 以 Quorum 机制保证多数节点存活即可服务

CAP 理论与分布式锁的关系

分布式系统中的 CAP 定理指出：一致性（Consistency）、可用性（Availability）、分区容错性（Partition Tolerance）三者不可兼得，最多只能同时满足其中两个。理解 CAP 是选型的前提。

选型思路：如果你的分布式锁用于保护金融交易、库存扣减等对数据一致性要求极高的操作，倾向选择 etcd 或 ZooKeeper 这类 CP 系统；如果用于排行榜刷新、限流计数等对偶尔不一致有一定容忍度的场景，Redis 的效率和可用性更具优势。

此外，分布式锁在面对网络分区时还会面临一个更棘手的问题：客户端的局部脑裂。如果客户端 A 成功获取锁后，由于网络分区，它失去了与协调服务的连接，但它本地的业务仍在继续执行。此时如果协调服务的 TTL 到期，其他客户端 B 可能获取到同样的锁。当网络恢复后，可能出现 A 和 B 同时认为自己持有锁的情况。Redlock 算法和后续的幂等性设计都在不同程度上解决这一问题。

基于 Redis 的单实例锁：从 SETNX 到 SET NX EX

Redis 是目前最广泛使用的分布式锁实现方案。它的性能极高（单机 QPS 可达 10 万级），操作简单，几乎存在于每一个后端基础设施中。但 Redis 锁的实现细节非常多，稍有不慎就会踩坑。

为什么不能用 SETNX + EXPIRE？

早期的分布式锁实现常常使用 SETNX key value 结合 EXPIRE key seconds 两条命令：

SETNX lock:order:123 "client-1"   # key 不存在时才设置
EXPIRE lock:order:123 30           # 设置 30 秒过期

这段代码存在一个致命的竞态条件：如果 SETNX 执行成功后，客户端在 EXPIRE 之前异常崩溃（例如进程被 Kill），这个 key 就永远不会过期，变成了一把永远无法释放的死锁。即便将两条命令用 Redis pipeline 发送也无法解决，因为 pipeline 不保证原子性，只是打包了网络往返。

Redis 2.6.12 的 SET 原子命令

Redis 2.6.12 版本引入了 SET key value [NX] [EX seconds] 语法，将设置 key 和设置过期时间合并为一条原子命令：

SET lock:order:123 "client-1" NX EX 30

参数含义：

• NX（Not eXists）：仅当 key 不存在时才设置
• EX 30：设置 30 秒的过期时间

这条命令在 Redis 服务端是原子执行的，要么成功设置并带 TTL，要么什么都不做。彻底解决了 SETNX+EXPIRE 的原子性问题。

锁标识：为什么必须用唯一 token

你以为 SET key 1 NX EX 30 就够了吗？还有一个更隐蔽的坑：误删他人的锁。

考虑这个场景：

1. 客户端 A 获取锁成功，设置 TTL=30 秒
2. 客户端 A 因 GC 暂停或业务逻辑复杂，执行了 35 秒
3. TTL 到期，锁被 Redis 自动删除
4. 客户端 B 获取锁成功
5. 客户端 A 恢复执行，执行 UNLOCKSCRIPT（DELETE lock:order:123）

此时 A 删除了 B 持有的锁！问题的根源在于 A 不知道自己持有的锁已经过期了，盲目释放导致互斥性被破坏。

解决方案：每个客户端在获取锁时生成一个全局唯一的 token（例如 UUID 或将「客户端 ID+线程 ID+时间戳」组合），释放锁时只有 token 匹配的客户端才能删除。

用 Lua 脚本实现原子化的"判断+删除"操作：

if redis.call("GET", KEYS[1]) == ARGV[1] then
    return redis.call("DEL", KEYS[1])
else
    return 0
end

这个脚本在 Redis 中作为单个命令执行，不存在 GET 和 DEL 之间的竞态窗口。

Redis 单实例锁的完整 Go 实现

下面给出基于 go-redis/v9 的完整 Redis 分布式锁实现：

type RedisLock struct {
	client    *redis.Client
	key       string
	token     string
	ttl       time.Duration
	stopRenew chan struct{}
	renewWg   sync.WaitGroup
	mu        sync.Mutex
}

func NewRedisLock(client *redis.Client, key string, ttl time.Duration) *RedisLock {
	return &RedisLock{client: client, key: key, ttl: ttl}
}

func (l *RedisLock) Lock(ctx context.Context) error {
	l.token = generateToken()
	for {
		ok, err := l.client.SetNX(ctx, l.key, l.token, l.ttl).Result()
		if err != nil { return err }
		if ok { l.startRenew(ctx); return nil }
		select {
		case <-ctx.Done(): return ctx.Err()
		case <-time.After(100 * time.Millisecond):
		}
	}
}

func (l *RedisLock) Unlock(ctx context.Context) error {
	l.mu.Lock(); defer l.mu.Unlock()
	if l.stopRenew != nil { close(l.stopRenew); l.renewWg.Wait() }
	script := redis.NewScript(`if redis.call("GET",KEYS[1])==ARGV[1] then return redis.call("DEL",KEYS[1]) else return 0 end`)
	result, _ := script.Run(ctx, l.client, []string{l.key}, l.token).Result()
	if result.(int64) == 0 { return errors.New("锁不被持有") }
	return nil
}

func (l *RedisLock) startRenew(ctx context.Context) {
	l.stopRenew = make(chan struct{})
	l.renewWg.Add(1)
	go func() {
		defer l.renewWg.Done()
		ticker := time.NewTicker(l.ttl / 3); defer ticker.Stop()
		for {
			select {
			case <-l.stopRenew: return
			case <-ctx.Done(): return
			case <-ticker.C:
				ms := int64(l.ttl / time.Millisecond)
				s := redis.NewScript(`if redis.call("GET",KEYS[1])==ARGV[1] then return redis.call("PEXPIRE",KEYS[1],ARGV[2]) else return 0 end`)
				s.Run(ctx, l.client, []string{l.key}, l.token, ms)
			}
		}
	}()
}

核心设计要点：（1）唯一 token：生成随机 Base64 token，Lua 脚本校验匹配后才能释放/续期；（2）看门狗续期：TTL/3 间隔续期，Unlock 时关闭 channel 并等待 goroutine 退出，避免泄漏；（3）阻塞与非阻塞：Lock 配合 context 用于可等待场景，TryLock 用于快速失败场景。

Redlock 算法：多 Redis 实例的分布式锁

Redlock 是 Redis 作者 antirez 提出的算法，在 N 个独立 Redis 主节点上执行加锁（典型值 N=5，允许 N/2 个宕机）。流程如下：

1. 记录开始时间 T1（单调时钟）
2. 并发向各节点请求加锁 SET NX EX，每个节点设置请求超时（如 10ms）
3. 计算 validity = TTL - (T2-T1) - clock_drift
4. 成功节点数 >= 半数（N/2+1）且 validity > 0，则加锁成功
5. 在所有节点执行解锁 Lua 脚本（清理可能的残留）

Redlock 的争议与工程折中

Martin Kleppmann（DDIA 作者）提出三点质疑：时钟漂移导致锁 TTL 变长不可控、客户端 GC 暂停影响锁有效期计算。更安全的方案是使用 fencing token（锁内嵌递增序号，数据层校验）。

工程实践：对绝大多数 Web 应用，Redis Cluster 或 Sentinel 已足够健壮。真正需要强一致性的系统（金融核心），选择 etcd/ZooKeeper 等 CP 系统更为稳妥。

Redlock 的 Go 实现

真实生产环境建议直接使用成熟的库 github.com/go-redsync/redsync，它基于 go-redis 实现了完整的 Redlock 协议，包括看门狗续期、锁重入等功能。以下展示核心逻辑：

func (rl *RedLock) Lock() (string, error) {
	value := generateRandomValue()
	start := time.Now()
	var success int
	var mu sync.Mutex

	// 并发向 N 个 Redis 实例发送加锁请求
	var g errgroup.Group
	for _, c := range rl.clients {
		g.Go(func() error {
			ctx, cancel := context.WithTimeout(context.Background(), c.timeout)
			defer cancel()
			ok, err := c.rdb.SetNX(ctx, rl.key, value, rl.ttl).Result()
			if err == nil && ok {
				mu.Lock(); success++; mu.Unlock()
			}
			return nil // 超时或失败不阻断，记录成功数即可
		})
	}
	g.Wait()

	elapsed := time.Since(start)
	validity := rl.ttl - elapsed - 2*time.Millisecond

	if success >= rl.quorum && validity > 0 {
		return value, nil
	}
	// 未满足多数派，释放已加锁节点
	_ = rl.Unlock(value)
	return "", ErrQuorumFailed
}

并发加锁 + 独立超时（context.WithTimeout）的设计，确保单个慢节点不会拖累整体进度。失败时向所有已成功的节点发送解锁 Lua 脚本清理残留。

基于 etcd 的分布式锁

相比 Redis 的最终一致性模型，etcd 提供了基于 Raft 共识协议的强一致性保证。在分布式锁这个场景下，etcd 的设计哲学与 Redis 有着本质的不同。

etcd 一致性保证：为什么选择 etcd

etcd 是一个高可用的分布式键值存储系统，被 Kubernetes 作为核心元数据存储广泛使用。它基于 Raft 共识算法实现了线性一致性（Linearizable）的读操作，这意味着：

• 一旦一个写操作被集群确认成功，后续任何从任何节点发起的读操作都一定能看到这个写入结果。
• 不存在 Redis 主从复制中的"异步延迟"——主节点写入成功，但从节点可能尚未同步。

对于分布式锁而言，强一致性意味着：锁释放后任何客户端都能立即感知到，不会有 Redis 主从复制那种"主节点已删除、从节点仍可读"的延迟窗口。这是 etcd 在分布式锁场景中最根本的优势。

etcd 分布式锁的核心机制

etcd 通过三个核心机制实现分布式锁：

1. Lease（租约）TTL

etcd 中的 key 可以绑定到一个 lease 上。lease 有一个 TTL（比如 30 秒），如果 lease 没有被续约（keepalive），TTL 到期后与其绑定的所有 key 会自动被删除。这与 Redis 的 key 过期行为类似，但 etcd 的 keepalive 是客户端向服务器发起的长连接，服务器在连接存活期间不断自动延长 TTL，不需要客户端定时发送续约命令。

2. Revision 与公平性

ectd 的每次写入（PUT/DELETE/TXN）都会生成一个全局单调递增的 revision。客户端可以通过 rev 排序来实现公平锁：当多个客户端同时等待同一个锁时，先发起请求的客户端（具有更小的 revision）优先获得锁。这比 Redis 锁的"随机重试"更加公平。

3. Watch 机制

etcd 提供了高效的监听机制。当锁被释放时，等待锁的客户端不需要轮询（polling），只需在删除事件发生前设置好 watch，就能在锁释放的第一时间收到通知。这与 ZooKeeper 的 watcher 机制类似，但 etcd 的 watch 无需"一次性注册"，可以在一个流式连接上持续接收变更事件。

etcd 分布式锁的 Go 实现

下面是使用 etcd client v3 的完整分布式锁实现：

type EtcdLock struct {
	client  *clientv3.Client
	key     string
	leaseID clientv3.LeaseID
	ttl     time.Duration
	mu      sync.Mutex
	locked  bool
}

func (l *EtcdLock) Lock(ctx context.Context) error {
	l.mu.Lock(); defer l.mu.Unlock()
	// 1. 创建 Lease
	lease, err := l.client.Grant(ctx, int64(l.ttl.Seconds()))
	if err != nil { return err }
	l.leaseID = lease.ID

	// 2. 启动 KeepAlive 自动续期（服务端维护，无需定时发送）
	kaCh, err := l.client.KeepAlive(ctx, l.leaseID)
	if err != nil {
		l.client.Revoke(context.Background(), l.leaseID); return err
	}
	go func() { for range kaCh {} }() // 消费 channel 保持连接

	// 3. 事务：createRevision==0 时才创建 key，保证互斥
	if err := l.tryLock(ctx); err != nil {
		l.client.Revoke(context.Background(), l.leaseID); l.leaseID = 0
		return err
	}
	l.locked = true; return nil
}

func (l *EtcdLock) tryLock(ctx context.Context) error {
	resp, _ := l.client.Txn(ctx).
		If(clientv3.Compare(clientv3.CreateRevision(l.key), "=", 0)).
		Then(clientv3.OpPut(l.key, "locked", clientv3.WithLease(l.leaseID))).
		Else(clientv3.OpGet(l.key)).Commit()
	if resp.Succeeded { return nil }
	// 锁已被持有，公平等待：watch 监听删除事件
	for wresp := range l.client.Watch(ctx, l.key) {
		for _, ev := range wresp.Events {
			if ev.Type == clientv3.EventTypeDelete { return l.tryLock(ctx) }
		}
	}
	return errors.New("获取锁失败")
}

func (l *EtcdLock) Unlock(ctx context.Context) error {
	l.mu.Lock(); defer l.mu.Unlock()
	if !l.locked { return errors.New("锁未持有") }
	l.client.Delete(ctx, l.key)
	l.client.Revoke(ctx, l.leaseID)
	l.leaseID, l.locked = 0, false
	return nil
}

etcd 锁核心设计要点

1. Lease + KeepAlive：服务端通过 TCP 长连接自动续期，即使客户端 GC 暂停也不影响 lease 存活，比 Redis 看门狗更抗抖动
2. CreateRevision 条件判断：CreateRevision == 0 代表 key 不存在，这个判断比简单的 value 比较更本质可靠
3. Watch 高效等待：获取失败后订阅 key 的删除事件，锁释放时立即重新事务竞争，无需轮询

生产环境建议：使用官方 concurrency 包

etcd v3 官方提供了 go.etcd.io/etcd/client/v3/concurrency 包，封装了完整的分布式锁、选举和 STM（软件事务内存）实现。生产环境中建议优先使用官方实现：

package main

import (
	"context"
	"fmt"
	"time"

	"go.etcd.io/etcd/client/v3"
	"go.etcd.io/etcd/client/v3/concurrency"
)

func main() {
	cli, err := clientv3.New(clientv3.Config{
		Endpoints:   []string{"localhost:2379"},
		DialTimeout: 5 * time.Second,
	})
	if err != nil {
		panic(err)
	}
	defer cli.Close()

	s, err := concurrency.NewSession(cli, concurrency.WithTTL(30))
	if err != nil {
		panic(err)
	}
	defer s.Close()

	mu := concurrency.NewMutex(s, "/my-lock/")
	ctx := context.Background()

	if err := mu.Lock(ctx); err != nil {
		panic(err)
	}
	fmt.Println("获取 etcd 锁成功")

	// 执行业务逻辑...

	if err := mu.Unlock(ctx); err != nil {
		panic(err)
	}
	fmt.Println("释放 etcd 锁成功")
}

concurrency.Mutex 内部使用了与上述实现相同的 Lease + Txn + Watch 机制，但增加了更多边界处理（如 session 过期检测、重试策略等），经过了大规模生产环境的验证。

基于数据库的乐观锁：版本号与 CAS 更新

分布式锁并非总是必要条件。在很多业务场景中，数据库本身就具备足够的能力来处理并发控制，尤其是通过乐观锁（Optimistic Locking）机制。

乐观锁与悲观锁的本质区别

悲观锁的核心是"先占坑"——通过 SELECT FOR UPDATE 或分布式锁，在逻辑执行前就确保独占访问。缺点是持锁期间其他操作全部阻塞，吞吐量受限。

乐观锁的核心是"最后把关"——允许多个操作同时执行，但在提交修改时检查数据是否被其他事务修改过（通过版本号或条件表达式）。如果检测到冲突，事务回滚并重试。

版本号模式

在数据表中增加一个 version 字段，每次更新时要求 WHERE version = ?，同时 SET version = version + 1：

CREATE TABLE products (
    id BIGINT PRIMARY KEY,
    name VARCHAR(255) NOT NULL,
    stock INT NOT NULL DEFAULT 0,
    version BIGINT NOT NULL DEFAULT 0,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

扣减库存的 SQL：

UPDATE products
SET stock = stock - 1, version = version + 1
WHERE id = 1 AND stock >= 1 AND version = 5;

如果返回的受影响行数为 0，说明在读取 version = 5 到执行更新之间，有其他事务修改了这条记录。此时应当重试或返回失败。

CAS（Compare And Swap）模式

CAS 更通用，不依赖额外的版本号字段，直接基于业务条件进行判断：

UPDATE products
SET stock = stock - 1
WHERE id = 1 AND stock >= 1;

这个 SQL 就是一个 CAS 操作：条件是 stock >= 1，效果是 stock = stock - 1。如果执行后 RowsAffected() == 0，说明库存不足或已被其他事务修改。

Go 实现乐观锁库存扣减

package dboptimistic

import (
	"context"
	"database/sql"
	"errors"
	"fmt"
	"time"
)

var ErrInsufficientStock = errors.New("库存不足")
var ErrConcurrentUpdate = errors.New("并发更新冲突")

// Product 商品模型
type Product struct {
	ID        int64
	Name      string
	Stock     int
	Version   int64
}

// DecrementStock 使用乐观锁扣减库存
func DecrementStock(ctx context.Context, db *sql.DB, productID int64, quantity int) error {
	maxRetries := 3
	backoff := 10 * time.Millisecond

	for attempt := 0; attempt < maxRetries; attempt++ {
		// 步骤 1：读取当前库存和版本号
		var p Product
		row := db.QueryRowContext(ctx,
			"SELECT id, name, stock, version FROM products WHERE id = ?",
			productID,
		)
		if err := row.Scan(&p.ID, &p.Name, &p.Stock, &p.Version); err != nil {
			if errors.Is(err, sql.ErrNoRows) {
				return fmt.Errorf("商品不存在")
			}
			return fmt.Errorf("查询商品失败: %w", err)
		}

		// 步骤 2：检查库存是否充足
		if p.Stock < quantity {
			return ErrInsufficientStock
		}

		// 步骤 3：执行 CAS 更新
		result, err := db.ExecContext(ctx,
			"UPDATE products SET stock = stock - ?, version = version + 1 WHERE id = ? AND version = ?",
			quantity, productID, p.Version,
		)
		if err != nil {
			return fmt.Errorf("更新库存失败: %w", err)
		}

		affected, _ := result.RowsAffected()
		if affected > 0 {
			// 更新成功
			return nil
		}

		// 第 4 步：版本号已变，等待后重试
		select {
		case <-ctx.Done():
			return ctx.Err()
		case <-time.After(backoff):
			backoff *= 2 // 指数退避
		}
	}

	return ErrConcurrentUpdate
}

乐观锁的适用场景与限制

适用场景：

• 数据读多写少，并发冲突概率低（冲突率低于 5% 时效率最高）
• 业务逻辑不复杂，重试成本较低
• 已有数据库依赖，不希望引入 Redis/etcd 等额外中间件

限制：

• 冲突率高时，频繁重试导致性能急剧下降，此时悲观锁（分布式锁或数据库行锁）更合适
• 无法处理跨多个无关联数据表的操作一致性（此时需要分布式事务或 Saga 模式）
• 重试逻辑需要自己实现，增加了代码复杂度

乐观锁与分布式锁并非互斥关系。在高并发秒杀等场景中，常见的最佳实践是：先用分布式锁限制并发线程数（如允许最多 1000 个 goroutine 同时进入），然后在每个 goroutine 内部使用乐观锁扣减库存，这样既能减少数据库压力，又能利用乐观锁的无锁特性保证正确性。

基于 ZooKeeper 的分布式锁

ZooKeeper 是 Apache 基金会下的分布式协调服务，早于 etcd 问世，同样基于类 Paxos 的 ZAB（Zookeeper Atomic Broadcast）协议，提供强一致性保证。在 Kubernetes 兴起之前，ZooKeeper 几乎是分布式协调的事实标准。

核心原理：临时顺序节点

ZooKeeper 的数据结构是一个类似文件系统的树形命名空间。分布式锁的实现基于两种特殊节点类型：

1. 临时节点（Ephemeral Node）

客户端创建的临时节点与客户端 session 绑定。当客户端 session 过期（例如客户端进程崩溃或网络断开），所有该客户端创建的临时节点会被 ZooKeeper 自动删除。这正是分布式锁防死锁的关键——即使持有锁的客户端异常退出，它的锁节点也会被清理。

2. 顺序节点（Sequential Node）

创建顺序节点时，ZooKeeper 会自动在节点名后追加一个单调递增的序号。例如客户端创建 /locks/order/lock- 时，实际创建的可能是 /locks/order/lock-0000000001。借助序号，可以实现公平锁：序号最小的节点优先获得锁。

加锁与解锁流程

假设锁的路径为 /locks/order：

加锁：

1. 客户端在 /locks/order 下创建一个临时顺序节点，如 lock-0000000003
2. 客户端获取 /locks/order 下所有子节点，排序后看自己的序号
3. 如果自己是序号最小的节点（例如前面只有 0001 和 0002，但 0001 已被删除），则获得锁
4. 如果不是最小的，客户端对排在自己前面且最接近自己的那个节点设置 watcher（例如当前是 0003，则监听 0002）
5. 当前面的节点被删除时，watcher 触发，当前客户端重新检查自己是否为最小序号

解锁：

1. 客户端完成业务逻辑后，直接删除自己创建的临时顺序节点
2. 此时排在后面的节点的 watcher 被触发，它发现自己成为了最小序号，获得锁

羊群效应的优化

在最初的 ZooKeeper 锁实现中，所有等待的客户端都监听同一个节点（如 lock-），当锁被释放时所有等待者同时被唤醒，但只有一个能获取到锁，其他重新进入等待。这种"羊群效应"（Herd Effect）导致大量不必要的网络开销。

优化方案是"链式监听"：每个客户端只监听排在自己前面最近的节点。当某个节点被删除时，只有一个客户端被唤醒，大大降低了通知风暴。上面的加锁流程第 4 步描述的正是这种优化。

ZooKeeper 锁的 Go 实现

ZooKeeper 锁的核心逻辑：创建临时顺序节点后，检查自己是否为最小序号——是则获得锁；否则监听前一个节点的删除事件，被触发后重新竞争。

func (l *ZKLock) Lock() error {
	// 创建临时顺序节点：如 /locks/order/lock-0000000003
	nodePath, _ := l.conn.Create(
		fmt.Sprintf("%s/lock-", l.basePath),
		[]byte{}, zk.FlagEphemeral|zk.FlagSequence, zk.WorldACL(zk.PermAll),
	)
	l.nodePath = nodePath

	for {
		children, _, _ := l.conn.Children(l.basePath)
		sort.Slice(children, func(i, j int) bool {
			return extractSeq(children[i]) < extractSeq(children[j])
		})
		nodeName := path.Base(l.nodePath)
		if children[0] == nodeName {
			return nil // 最小序号，获取成功
		}
		// 找到前一个节点，设置 watcher
		prevNode := findPrevNode(children, nodeName)
		exists, _, ch, _ := l.conn.ExistsW(
			fmt.Sprintf("%s/%s", l.basePath, prevNode))
		if !exists { continue } // 前一个节点已删，重试
		// 阻塞等待 watcher 通知
		if evt := <-ch; evt.Type == zk.EventNodeDeleted {
			continue
		}
	}
}

FlagEphemeral|FlagSequence 的组合节点既保证了进程退出自动释放（因 session 断开），又通过序号排序天然实现了公平锁（先请求的客户端优先）。每个等待者只监听前一个节点，消除了羊群效应。

在需要强一致性且已有 ZooKeeper 集群的环境中（如 Kafka、Hadoop 生态），ZK 锁是一个可靠的选择。

锁超时与续期策略：Watchdog 深度解析

所有基于外部存储的分布式锁都面临一个共同的矛盾：锁的 TTL 应该设多长？

• TTL 太长：如果客户端异常崩溃，其他客户端需要等待很久才能获得锁，降低了可用性
• TTL 太短：如果业务执行时间超过 TTL，锁被提前释放，互斥性被破坏

Watchdog（看门狗）机制正是为了解决这一矛盾。它的核心思想是：锁的持有者与一个后台 goroutine 绑定，只要持有者进程还活着，就持续不断地延长锁的 TTL；当持有者主动释放锁时，看门狗立即停止。

Watchdog 的设计考量

续期间隔的选择

续期间隔通常设为 TTL / 3。原因如下：

TTL = 30s, 续期间隔 = 10s（TTL/3）

时间轴：  0s    10s   20s   30s
         |------|------|------|
加锁 ==> o      o      o      锁释放
         续    续    续

• 单次续期失败不影响（如第 20 秒 packet 丢失），第 30 秒前有两次补救
• 客户端第 27 秒彻底失联，锁第 30 秒到期释放，等待者最多等 TTL

Redis 看门狗 vs etcd KeepAlive

续期失败应对策略

• 继续重试：非关键业务，容忍偶发失败
• 主动终止：金融级严格互斥，续期失败即锁不可靠，立即停止业务
• 业务内建检查点：长任务中定期验证锁 token 是否匹配，失效即退出

业务超时超过 TTL 的兜底

看门狗不是万能的：下游大面积超时、数据库死锁仍可能导致锁保护的业务跑不完。根本方案：

1. 限制单次锁保护逻辑的执行 deadline
2. 对长时间任务使用分布式任务调度框架（如 Temporal），而非简单分布式锁

• 调用的下游服务发生大面积超时
• 数据库死锁导致事务挂起
• 业务逻辑中存在不可预见的递归或循环

应对策略：

1. 业务内建超时控制：为每个锁保护的业务逻辑设置 execution context timeout，确保业务本身不会无限跑下去
2. 锁内嵌检查点：业务逻辑中每隔固定时间（如 10 秒）检查当前锁是否仍然有效（验证 token 是否匹配），如果不匹配则主动中止执行
3. 分布式任务框架：对于长时间任务，考虑使用独立的任务调度系统（如 Temporal、 Cadence 等），将任务分解为可追踪的 workflow，而非依赖简单的分布式锁

幂等性设计：分布式锁的安全兜底

分布式锁虽然在大多数情况下能够保证互斥性，但它不是绝对安全的。网络分区、时钟漂移、客户端 GC 暂停、锁存储节点故障——各种极端情况都可能导致锁被"同时持有"。

幂等性设计是分布式锁的最后一道防线。

什么是幂等性

幂等性（Idempotency）是指一个操作执行一次和执行多次产生的效果完全相同，不会因为重复执行导致数据错误。

在分布式系统中，幂等性往往比分布式锁更根本：即使锁机制完美无缺，网络重试、消息重复投递、客户端重发请求等情况依然会导致同一业务逻辑被多次执行。幂等性保证无论执行多少次，结果都是正确的。

Token 机制（唯一请求标识）

最常见的幂等性方案是为每个业务请求生成一个全局唯一的 token：

type IdempotencyKey struct {
	RequestID string    // UUID 生成，如 "req-550e8400-e29b-41d4-a716-446655440000"
	UserID    int64
	Action    string    // 如 "deduct_stock"
	CreatedAt time.Time
}

服务端收到请求时：先查 token 是否已处理（Redis/DB）——已处理直接返回；未处理则获取分布式锁（防止并发创建），执行业务，最后写入结果缓存。

func (p *IdempotentProcessor) Process(ctx context.Context, requestID string,
	processor func() (interface{}, error)) (interface{}, error) {
	key := "idempotent:" + requestID

	// 1. 检查是否已处理
	if cached, err := p.client.Get(ctx, key).Result(); err == nil {
		return jsonExtract(cached)
	}

	// 2. 获取短生命周期锁，防止并发创建
	if ok, _ := p.client.SetNX(ctx, "idempotent_lock:"+requestID, "1", 10*time.Second).Result(); !ok {
		time.Sleep(100 * time.Millisecond)
		if cached, err := p.client.Get(ctx, key).Result(); err == nil {
			return jsonExtract(cached)
		}
		return nil, errors.New("并发处理失败")
	}
	defer p.client.Del(ctx, "idempotent_lock:"+requestID)

	// 3. 双重检查（锁内再查一遍）
	if cached, err := p.client.Get(ctx, key).Result(); err == nil {
		return jsonExtract(cached)
	}

	// 4. 执行业务
	data, err := processor()
	if err != nil { return nil, err }

	// 5. 缓存结果 24 小时
	val, _ := json.Marshal(data)
	p.client.Set(ctx, key, val, 24*time.Hour)
	return data, nil
}

数据库唯一索引实现幂等性

对于涉及数据库写入的操作，可以在表中添加唯一索引：

CREATE TABLE idempotent_records (
    request_id VARCHAR(64) NOT NULL PRIMARY KEY,
    user_id BIGINT NOT NULL,
    action VARCHAR(64) NOT NULL,
    result JSON,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    INDEX idx_user_action (user_id, action)
);

在业务开始前先 INSERT INTO idempotent_records，利用数据库的唯一约束天然实现幂等性判断。如果插入失败（Duplicate Key），说明该请求之前已经被处理过。

分布式锁与幂等性的协同

分布式锁和幂等性不是二选一的关系，而是互为补充的：

• 分布式锁：控制"并发时的串行化"，降低冲突概率和系统负载
• 幂等性：保证"即使并发串行化失败或重试发生，结果依然正确"

最佳实践是：先用分布式锁减少并发竞争，再在锁保护的业务逻辑中嵌入幂等性校验，形成双重保险。锁的持有时间应尽量短（只保护检查和写入的原子性窗口），而幂等性token的长期存储则兜底了锁之外的各种意外场景。

方案对比与选型指南

选型决策树

是否需要强一致性保证？
├── 是 → 涉及资金/库存等关键数据
│     ├── 已有 etcd 集群？→ 使用 etcd concurrency.Mutex
│     └── 无 etcd，有 Redis？→ Redis 单实例 + 幂等性兜底
│         └── 仍不放心？→ 引入 etcd 或薛痛了
└── 否 → 限流、缓存、排行榜等非关键场景
      ├── 已有 Redis？→ go-redis + 自定义看门狗
      └── 无 Redis，使用数据库？→ 乐观锁 / SELECT FOR UPDATE

生产环境最佳实践

锁粒度控制

锁的粒度直接影响并发性能。推荐按资源 ID 细粒度命名：lock:product:stock:10086（单商品）而非 lock:product:stock（全局串行）。key 的命名规范建议 lock:<业务>:<资源类型>:<资源ID>，使用 : 分隔符便于 Redis KEYS 和 SCAN 运维查询。

降级策略

分布式锁服务不可用时，系统应有降级预案：

1. 硬失败（Fail-fast）：直接拒绝，最安全但体验差
2. 本地锁兜底：降级到进程内 sync.Mutex，适用于单实例部署或请求路由保证的场景
3. 业务兜底：跳过锁，依赖数据库唯一约束 + 幂等性 token

建议在配置中心实现降级开关，紧急时刻一键切换。

监控告警与故障演练

分布式锁必须纳入监控：锁获取成功率（低于 95% 告警）、锁持有时间 P99、续期失败次数、watch queue 长度等。

func monitoredLock(l *RedisLock, ctx context.Context) error {
	start := time.Now()
	err := l.Lock(ctx)
	metrics.LockDuration.Observe(time.Since(start).Seconds())
	metrics.LockAcquire.WithLabelValues("success", fmt.Sprintf("%t", err == nil)).Inc()
	return err
}

定期故障演练：模拟 Redis failover、网络分区（iptables/tc）、锁持有者 kill-9 进程、时钟漂移（libfaketime），验证系统行为。与限流（参考 熔断、降级与限流）和链路追踪（参考 分布式追踪）一样，可观测性是锁定一切异常的基石。

锁与 Context 的结合

在 Go 中，锁操作都应当接受 context.Context 参数（参考 Context：并发控制的指挥棒），以支持超时取消和链路追踪：

// 好的设计：锁接受 context
func (l *RedisLock) Lock(ctx context.Context) error

// 差的设计：锁自己管理超时
func (l *RedisLock) Lock(timeout time.Duration) error

使用 context 的好处：HTTP 超时自动传递、OpenTelemetry span 贯穿锁生命周期、优雅关闭时 context cancel 立即通知锁内的阻塞操作。

总结

分布式锁是分布式系统中协调并发资源访问的核心基础设施，但其实现比看上去复杂得多。本文从分布式锁的基本理论出发，深入剖析了五种主流方案的实现细节：

1. Redis 单实例锁：通过 SET key value NX EX 结合 Lua 脚本释放锁，配合看门狗续期，是最为广泛使用的方案。实现简单、性能极高，但要注意处理时钟漂移和主从切换期间的一致性问题。

2. Redlock 算法：在多个独立 Redis 节点上执行多数派加锁，提供了比单实例锁更高的容错性。但其对时钟同步的依赖和学术界的争议意味着它并非绝对的安全方案。

3. etcd 分布式锁：基于 Raft 强一致性协议，结合 Lease 的自动续期和事务的原子性，提供了分布式锁场景下最坚实的理论基础。Go 官方 clientv3/concurrency 包已经提供了生产级的封装。

4. ZooKeeper 分布式锁：利用临时顺序节点的 session 绑定和自然排序，实现了天然公平的锁竞争和自动防死锁。适合已有 ZooKeeper 基础设施的系统。

5. 数据库乐观锁：通过版本号或 CAS 条件更新，在不引入额外中间件的情况下实现并发控制。适合读多写少、冲突率低的场景。

分布式锁不是银弹，它与幂等性设计、限流降级、可观测性共同构成了分布式系统的韧性基础设施。一个健壮的系统设计应当是：锁用于降低冲突概率，幂等性用于保证最终正确性，限流用于保护系统不被打垮，可观测性用于在异常发生前提前预警。

下一步学习

• 想深入了解 Redis 在 Go 中的更多用法？参考 Redis 集成：高性能缓存与数据存储
• 对 Go 微服务的韧性设计感兴趣？学习 熔断、降级与限流：Go 微服务韧性设计完全指南
• 想追踪分布式锁在全链路中的执行状况？参考 分布式追踪：OpenTelemetry 在 Go 中的实践
• 对 etcd 底层 Raft 协议感兴趣？推荐阅读 Diego Ongaro 的博士论文 《In Search of an Understandable Consensus Algorithm》，理解 etcd 为何能提供线性一致性保证
• 考虑将分布式锁封装到框架层？参考 Go 项目结构与依赖注入 的模块化设计思路