分布式锁的三种实现方式对比

分布式锁几乎是每个涉及高并发场景项目的必答题——无论是毕设中的秒杀模块，还是面试中的系统设计环节。这篇文章横向对比三种主流实现方式，帮助你建立起选型的判断标准。

一、基于数据库的实现

利用唯一索引或 SELECT ... FOR UPDATE 实现互斥，实现简单但性能较差，且存在锁释放依赖事务提交、死锁排查困难等问题，通常只在低并发场景或作为兜底方案使用。

二、基于 Redis 的实现

// SETNX + EXPIRE 的原子化写法
Boolean success = redisTemplate.opsForValue()
    .setIfAbsent(lockKey, requestId, 30, TimeUnit.SECONDS);

Redis 锁的性能优势明显，是高并发场景下最常用的方案。但需要额外处理三个问题：锁的原子性（SET 命令的 NX + EX 参数）、锁的误删（校验持有者标识）、锁续期（看门狗机制，Redisson 已内置实现）。

三、基于 ZooKeeper 的实现

ZooKeeper 利用临时顺序节点与 Watcher 机制实现锁的公平排队与自动释放（客户端断连节点自动删除），可靠性优于 Redis 方案，但性能不如 Redis，通常用于对可靠性要求更高、并发量相对较低的场景，如分布式任务调度中的 Leader 选举。

• 数据库锁：实现简单，性能最差，适合低并发兜底场景
• Redis 锁：性能最好，需要处理续期与误删问题，适合高并发场景
• ZooKeeper 锁：可靠性最高，天然支持公平锁与自动释放，适合调度类场景

面试中被问"如何选型分布式锁"时，先讲清楚业务的并发量级与可靠性要求，再给出方案，比直接甩结论更能体现工程判断力。