分布式锁：Redis vs etcd — CAP定理下的两种范式

ABSTRACT / 摘要

分布式锁是微服务、分布式事务、定时任务、库存扣减等后端场景的基础并发原语，看似实现逻辑简单，却在网络抖动、节点宕机、进程卡死、时钟漂移等海量边界条件下潜藏数据一致性风险。行业主流存在两套成熟实现路线：基于 Redis 的 Redlock 与基于 etcd 的 Lease 租约锁，二者选型差异本质是 CAP 定理在工程落地层面的具象分歧。

本文将从分布式锁四大核心正确性指标切入，从零分步实现单节点 Redis 锁、Redlock 集群锁、etcd 租约锁，拆解底层原子指令、故障容错逻辑、时钟依赖缺陷，量化对比两套方案的一致性、性能、运维成本、故障表现。

01 / FOUNDATION

四大刚性正确性约束

无论基于何种中间件实现，一套工业可用的分布式锁必须同时满足以下四大核心特性。缺少任意一项，都会在极端故障下引发超卖、重复执行、数据脏写等线上事故。

01

互斥性

CORE BOTTOM LINE

同一时刻，仅有一个客户端能持有目标锁资源，杜绝多进程并发执行业务临界逻辑，是分布式锁存在的根本目的。

02

死锁自愈

ANTI-PERMANENT BLOCK

客户端持有锁后进程崩溃、网络断连、服务宕机时，锁必须自动释放，避免其他线程永久阻塞。行业通用方案为过期时间 / 租约自动回收。

03

锁防劫持

ANTI-HIJACK

客户端 A 持有的锁过期后，客户端 B 抢占锁；此时 A 恢复执行释放锁，不能误删 B 持有的锁，必须通过唯一标识区分锁归属。

04

锁连续性保障

CONTINUITY GUARD

业务执行时长超过锁过期时间时，不能提前释放锁导致临界逻辑并发，需配套锁自动续期（看门狗 / 租约心跳）机制。

// 同时，分布式锁的所有加锁、解锁、续期逻辑必须原子执行。拆分多步网络指令会引入窗口故障，破坏互斥约束。

AP SYSTEM 02 / REDIS

Redis 分布式锁：从单节点缺陷到 Redlock

Redis 基于内存操作、单命令原子性、高性能 IO 特性，是互联网业务最常用的分布式锁载体。但 Redis 原生架构是 AP 系统，集群主从切换、异步复制会破坏一致性，存在天然缺陷。

2.1 单节点基础锁

SET key value NX EX ttl 是单条原子指令，一次性完成「不存在则写入 + 设置过期时间」，规避分两步 SETNX + EXPIRE 带来的进程宕机死锁风险。

              
              lock.redis
            
# key：锁标识；value：客户端全局唯一 UUID（防锁劫持）
# NX 不存在才写入；EX 过期秒数
SET stock_lock uuid-xxxx NX EX 30

解锁必须原子校验归属再删除，使用 Lua 脚本保证多判断逻辑原子执行：

              
              
              
              unlock.lua
            
-- 仅当前持有者可删除锁
if redis.call("GET", KEYS[1]) == ARGV[1] then
    return redis.call("DEL", KEYS[1])
else
    return 0
end

2.1.2 致命故障场景

单节点 Redis 仅适用于非核心、允许少量数据不一致的业务。核心库存、资金系统绝对禁用。

FAULT 01

主节点宕机未同步至从库

客户端加锁成功写入主库，主库崩溃、从库晋升新主；锁数据尚未异步复制到从节点，新主无锁记录，其他客户端可重复加锁，互斥性彻底失效。

FAULT 02

业务执行超期，锁提前过期

30 秒过期锁，业务执行耗时 40 秒，锁自动释放，其他线程抢占锁，双进程并发执行临界区，数据错乱。

2.1.3 看门狗自动续期

加锁成功后启动定时任务，每 ttl/3 时长执行 EXPIRE 续期；业务正常释放后终止看门狗，进程崩溃则停止心跳，锁自然过期。

⚠ 缺陷：看门狗依赖客户端常驻线程，容器、云函数无常驻进程场景无法使用。

2.2 / REDLOCK ALGORITHM

Redlock：官方集群分布式锁

Redis 作者提出 Redlock 算法，采用 N 个独立、无主从关系、异步复制的 Redis 独立节点，放弃集群主从复制架构，通过多数派投票保证互斥性。

标准加锁流程

01

客户端生成全局唯一锁标识 UUID，记录本地时间戳

02

按随机顺序，向全部 N 台独立 Redis 节点执行原子 SET 加锁指令

03

统计成功节点数 > N/2（多数派），且总耗时 < 锁有效期 → 加锁成功

04

未达多数派 → 向所有已加锁节点同步执行解锁 Lua 脚本

05

业务执行期间启动看门狗，持续向所有节点续期

底层固有缺陷

Redlock 是 AP 架构下的妥协方案，存在两大无法根治的硬伤，是学术界与工业界长期争议的核心。

DEFECT 01

强依赖服务器系统时钟同步

算法判定逻辑依赖本地时间戳计算加锁总耗时。若任意 Redis 节点发生时钟回拨、NTP 时间跳跃，会出现锁未过期但判定失效，多客户端同时持有锁。etcd 基于租约心跳完全规避时钟依赖。

DEFECT 02

性能与运维成本翻倍

加锁 / 解锁 / 续期均需访问全部 N 台节点，网络 IO 次数线性增长；需维护 N 套独立 Redis 实例，无法复用现有主从集群。

DEFECT 03

网络分区下可用性与一致性无法兼顾

客户端与过半节点网络隔离时，Redlock 直接加锁失败，牺牲可用性换取一致性，与 Redis 本身 AP 高可用的设计初衷冲突。

CP SYSTEM 03 / ETCD

etcd 租约锁：CP 强一致范式

etcd 底层基于 Raft 一致性算法，是标准 CP 分布式系统，天然提供强一致、线性化读写、租约自动过期、Watch 事件监听能力。其分布式锁依托原生租约机制实现，从底层规避 Redis 锁的复制延迟、时钟漂移缺陷。

3.1 Lease 租约机制原理

etcd 租约是独立于 KV 存储的心跳过期体系，与 Redis TTL 有本质区别：

1

客户端向 etcd 服务端申请租约，设置 TTL，服务端生成唯一租约 ID

2

客户端定时发送 KeepAlive 心跳维持租约，心跳中断则租约到期，绑定该租约的所有 KV 键自动删除

3

租约过期由服务端主动判定，不依赖客户端本地系统时钟，完全消除时钟漂移风险

3.2 完整原子实现

etcd 提供 CompareAndSwap (CAS) 原子事务接口，配合租约实现满足四大约束的分布式锁：

              
              lock.etcd — CAS Transaction
            
// 事务条件：锁 key 不存在（revision=0）
// 写入当前客户端唯一标识，并绑定租约 ID
If: key="stock_lock", mod_revision == 0
Then: put key="stock_lock", value=uuid, lease=leaseId

UNLOCK / 主动释放

撤销租约 Revoke Lease，所有绑定锁键立即删除

UNLOCK / 进程崩溃

心跳中断，租约自动过期，服务端清理锁资源，天然防死锁

3.2.3 / WATCH

阻塞优化

etcd 支持 Watch 监听锁 Key 删除事件，加锁失败时阻塞监听，锁释放后主动唤醒客户端，大幅降低轮询 IO 开销。

3.3 / CONSISTENCY

Raft 线性读写

所有写入必须同步至过半节点才返回成功，不存在主从异步复制丢失锁数据的场景，主节点宕机切换后锁状态完整保留。

3.3 / HEARTBEAT

原生协程心跳

etcd 客户端内置 KeepAlive 心跳，租约续租由服务端状态驱动，无需业务侧维护看门狗，云函数、短期进程适配性更强。

核心优势 ▸ etcd 完全不依赖系统本地时钟。租约过期依靠服务端心跳计数，加锁成功判定无需对比客户端时间戳，NTP 时钟回拨、服务器时间跳跃不会破坏锁正确性。

04 / COMPARISON

全维度专业对比

从分布式理论、工程正确性边界、性能运维三个层面，量化对比两套方案。

4.1 分布式理论层面

对比维度	Redis Redlock	etcd Lease
底层分布式模型	AP 系统，放弃强一致优先高可用	CP 系统，强一致优先，分区时牺牲可用性
一致性算法	无共识算法，依赖多节点多数派投票	Raft 线性一致性，写入过半节点落盘
时钟依赖	强依赖各节点系统时间同步	租约心跳计数，完全脱离系统时钟
主从复制风险	异步复制，主宕机锁数据丢失	Raft 同步复制，故障切换锁状态无丢失

4.2 工程正确性边界

故障场景	Redis Redlock	etcd Lease
主节点宕机、未同步锁数据	未达多数派则锁失效，并发击穿	Raft 过半节点已落盘，锁状态完整保留
服务器 NTP 时钟回拨	锁提前判定过期，多客户端同时持有	无影响，租约过期由心跳控制
客户端进程卡死、无心跳	看门狗停止，TTL 到期释放	KeepAlive 中断，租约自动回收
网络分区隔离过半节点	加锁直接失败，业务阻塞	写入必须过半节点，分区期间无法抢占
锁持有者误删他人锁	Lua 脚本校验 UUID，可规避	CAS 事务绑定租约 ID，天然隔离

4.3 性能、运维、业务适配

指标	Redis Redlock	etcd Lease
单锁 IO 次数	加锁访问 N 台独立节点，IO 开销高	仅单次事务请求，性能更高
单机吞吐上限	内存读写，单节点 QPS 极高	Raft 日志同步，吞吐低于 Redis，足够万级并发
运维成本	多套独立 Redis 实例，不能复用现有集群	复用业务 etcd 集群，零额外部署
适配业务	高并发非核心业务，允许极小概率不一致	资金、库存、分布式事务、强一致场景
云原生适配	容器时钟漂移风险高，看门狗占用资源	原生支持短期进程、Serverless，心跳内置

05 / STRATEGY

工程落地选型策略

没有银弹。基于业务场景匹配正确的实现方案，是规避线上资损事故的第一道防线。

R

选择 Redis

包括 Redlock

▸

高吞吐非核心业务：定时任务去重、日志合并、缓存刷新，允许万分之一概率并发问题

▸

现有系统重度依赖 Redis，无独立 etcd 集群，运维资源有限

▸

纯流量削峰场景，数据不一致无资金、资损风险

落地强制规范

禁止单节点 Redis 锁；核心业务必须实现完整 Redlock；部署时间同步服务规避时钟漂移；强制 Lua 脚本解锁 + 看门狗续期。

E

选择 etcd

Lease 租约锁

▸

强一致性核心业务：商品库存扣减、订单创建、资金交易、分布式事务

▸

微服务原生依赖 etcd 做配置中心 / 注册中心，可复用集群

▸

Serverless 云函数、短期任务、无常驻进程的业务

▸

对故障容错、数据正确性零容忍，无法接受超卖、重复执行资损

落地强制规范

长租约 + 高频心跳；Watch 阻塞等待；租约撤销兜底；事务 CAS 原子化；集群 3 节点以上部署。

5.3 行业避坑红线

RED LINE 01

资金、库存场景严禁使用单节点 / 主从 Redis 锁，异步复制宕机必然出现资损

RED LINE 02

追求强一致时不要选用 Redlock，时钟依赖漏洞无法彻底修复，学术界不认可其强一致能力

RED LINE 03

etcd 集群不可缩至 2 节点，Raft 算法至少 3 节点才能完成故障自动切换

06 / CONCLUSION

CAP 定理的工程具象体现

A · P

Redis 生态以可用性 (A) 为第一优先级，牺牲部分一致性 (C) 换取极致吞吐与故障快速恢复。Redlock 只是在 AP 框架下做一致性补偿，无法根除时钟、复制带来的一致性漏洞。

C · P

etcd 依托 Raft 共识算法，以一致性 (C) 为核心目标，网络分区时主动牺牲可用性 (A)，从底层存储层保证锁的互斥性永不破坏，适配所有对数据正确性有硬性要求的核心业务。

分布式锁看似简单的加锁 — 执行业务 — 解锁三段逻辑，实则串联分布式共识、网络故障容错、系统时钟、内存持久化、租约生命周期整套分布式理论。

绝大多数线上分布式锁事故，并非代码实现错误，而是选型阶段忽略底层 CAP 取舍，将 AP 架构的 Redis 锁用于需要 CP 强一致的资金、库存场景。

EXTENDED

生产级兜底降级方案

核心业务可采用「etcd 锁为主，本地内存锁为辅」双重互斥防护，进一步降低极端故障并发概率。同时强制实现：Redis 独立多实例部署 + 随机节点访问顺序 + 看门狗协程生命周期绑定；etcd 长租约 + 高频心跳 + Watch 阻塞等待 + 租约撤销兜底。

07 / REFERENCES

参考文献

[1]

Redis 官方 Redlock 算法设计文档与作者时钟缺陷说明

[2]

etcd Raft 共识算法与 Lease 租约官方规范

[3]

CAP 定理分布式系统工程落地分析论文

[4]

分布式系统互斥锁工业级故障复盘白皮书

[5]

Redis 与 etcd 分布式锁学术界一致性对比评测报告

分布式锁 Redis vs etcd