1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

单机：用 lock / Mutex / 信号量（进程内）

分布式：多个进程/机器要互斥
  单机锁管不到其他机器
  需要一个"全局可见"的锁

典型场景：
  - 防止重复操作（下单、扣库存、发券）
  - 限流（全局 QPS）
  - 选主（只一个节点执行定时任务）
  - 资源独占（同时只一个能改配置）

1
2
3
4
5
6
7

分布式锁的必要条件：
  ✓ 互斥（Mutual Exclusion）— 任意时刻只有一个客户端持有
  ✓ 避免死锁 — 持有者崩溃，锁要能自动释放
  ✓ 可重入（可选）— 同一持有者可重复获取
  ✓ 高可用 — 锁服务不能单点
  ✓ 高性能 — 加锁/解锁要快
  ✓ 公平性（可选）— 按请求顺序获取

1
2
3
4
5
6

方式          一致性    性能    可靠性    复杂度    适用
──────────────────────────────────────────────────────────
数据库         强       中      中       低        简单场景
Redis         弱(AP)   极高    中       低        高并发、容忍偶尔失效
Zookeeper     强(CP)   中      高       中        强一致、可靠
etcd          强(CP)   高      高       中        云原生、K8s

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

-- 方式一：唯一索引（加锁 = 插入，解锁 = 删除）
INSERT INTO locks(resource, owner, expire_at) VALUES('order:123', 'uuid', NOW()+10s);
-- 插入成功 = 获取锁；唯一冲突 = 被占
DELETE FROM locks WHERE resource='order:123' AND owner='uuid';

-- 方式二：悲观锁（SELECT ... FOR UPDATE）
BEGIN;
SELECT * FROM account WHERE id=1 FOR UPDATE;   -- 加行锁
-- 业务
COMMIT;

1
2
3

优点：简单，不用引入新组件
缺点：性能差（DB 是瓶颈）、过期清理麻烦、FOR UPDATE 占连接
适用：并发不高、已有数据库、不想引入 Redis/ZK

1
2
3
4
5
6
7
8

# 加锁：SET key value NX EX（原子）
SET lock:order:123 <owner_uuid> NX EX 10
# NX：不存在才设置（互斥）
# EX 10：10 秒过期（防死锁）
# 返回 OK = 获取成功；nil = 已被占

# 解锁：必须验证 owner 再删（Lua 保证原子）
# 否则可能删掉别人的锁

1
2
3
4
5
6

-- 解锁脚本（原子）
if redis.call('get', KEYS[1]) == ARGV[1] then
    return redis.call('del', KEYS[1])
else
    return 0
end

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

问题1：业务执行超过锁过期时间
  锁到期自动释放，别的客户端拿到锁 → 两个客户端同时执行
  解决：看门狗续期（定时延长过期时间）
  Redisson 框架自带看门狗

问题2：Redis 主从切换丢锁
  主节点加锁成功 → 还没同步到从 → 主挂了 → 从升主（没锁数据）→ 别人能加锁
  解决：Redlock（向多个独立 Redis 实例加锁，多数成功才算成功）

问题3：Redlock 的争议
  Martin Kleppmann 认为 Redis（AP）做锁不可靠
  因为 GC 停顿、时钟漂移可能导致锁失效
  Redis 作者 antirez 反驳（认为实际够用）

1
2
3
4
5

Redis 锁的定位：
  ✓ 高性能、高并发
  ✗ 不是绝对可靠（AP 系统的特性）
  适用：对偶尔失效容忍的场景（如限流、防重复提交）
  不适用：绝对不能错的场景（如扣款、扣库存）→ 用 ZK/etcd

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

ZK 锁基于「临时顺序节点」+ Watch：

1. 创建顺序临时节点 /lock/node-0001, /lock/node-0002 ...
2. 判断自己是不是序号最小的
   - 是 → 获得锁
   - 否 → 监听前一个节点（只监听前一个，避免羊群效应）
3. 前一个节点删除（释放锁）→ 自己被唤醒 → 成为最小 → 获得锁
4. 持有者崩溃 → 临时节点自动删除 → 后继者被唤醒

特点：
  ✓ 强一致（ZAB 共识）
  ✓ 公平锁（顺序节点）
  ✓ 会话失效自动释放（临时节点）
  ✓ 无看门狗问题（会话心跳保活）
  ✗ 性能不如 Redis（CP，要多数确认）

1
2
3

羊群效应（Herd Effect）：
  ✗ 所有等待者都监听同一个节点 → 释放时全部唤醒抢锁 → 惊群
  ✓ 改进：每个等待者只监听「前一个」节点 → 顺序唤醒

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

etcd 锁基于 Lease（租约）+ 事务（TXN）+ Revision（全局递增版本）：

1. 创建带 Lease 的 key（Lease 保活，崩溃自动过期）
2. 用事务获取所有锁 key，判断自己 Revision 是否最小
   - 是 → 获得锁
   - 否 → 监听前一个 key
3. 类似 ZK 的顺序等待

特点（类似 ZK）：
  ✓ 强一致（Raft）
  ✓ Lease 自动过期（防死锁）
  ✓ 比 ZK 更轻量、性能更好、云原生标配
  K8s 的分布式锁多用 etcd（或基于 etcd 的 leader election）

1
2
3
4
5
6

// etcd 分布式锁示例（Go concurrency 包）
m, err := concurrency.NewSession(client)
l := concurrency.NewMutex(m, "/lock/order/123")
l.Lock(ctx)      // 加锁
defer l.Unlock(ctx)
// 业务

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

Redis 锁（AP）：
  返回"加锁成功"时，可能主从还没同步
  极端情况下锁可能失效（但你以为成功）
  → 快，但不可靠

ZK / etcd 锁（CP）：
  返回"加锁成功"时，数据已通过共识写入多数节点
  强一致保证，不会假成功
  → 可靠，但慢

选择：
  需要绝对可靠（金融、库存）→ CP（ZK/etcd）
  容忍偶尔失效、追求性能   → AP（Redis）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

场景                          推荐
──────────────────────────────────────────────────
高并发、容忍偶尔失效（限流）   Redis
防重复提交、幂等               Redis
扣库存、扣款（绝对不能错）     ZK / etcd / 数据库
选主（Leader Election）        ZK / etcd
配置/资源互斥                  etcd（云原生）/ ZK

通用建议：
  优先用成熟框架（Redisson、curator、etcd concurrency）
  别自己造轮子（边界情况极多）
  锁要设过期时间 + 校验 owner
  业务要考虑"锁失效"的兜底（幂等）