分布式锁 实现方案实践
大家好，我是程序员老王。今天咱们聊聊面试高频题——分布式锁的实现方案。在分布式系统中协调多个节点对共享资源的访问，分布式锁是必备技能。下面结合实战经验，分析几种主流实现方案的优缺点。
👉 2025年Java面试宝典最新版：
链接: https://pan.baidu.com/s/1RUVf75gmDVsg8MQp4yRChg?pwd=9b3g
提取码: 9b3g
为什么需要分布式锁？
当服务部署在多台机器时，传统的单机锁（如synchronized）失效。比如秒杀扣库存场景，必须保证集群中只有一个节点能执行减库存操作，否则会导致超卖。这就是分布式锁的核心价值——跨进程的互斥访问。
主流实现方案对比
1. 基于Redis的分布式锁
实现方案核心命令：SET key value NX PX 30000
- 优点：性能极高，实现简单（Redis原生支持）
- 致命坑：
- 锁过期时间难评估（业务未执行完锁已释放）
- 主从切换可能导致锁失效（Redlock算法有争议）
graph LR
A[客户端A加锁成功] --> B[Redis主节点宕机]
B --> C[从节点升级为主]
C --> D[客户端B加锁成功]
D --> E[同一资源被两个客户端同时操作]
适用场景：对一致性要求不高的高频读写（如缓存更新）
2. 基于Zookeeper的分布式锁
实现方案本质：创建临时有序节点
- 绝对优势：强一致性（ZAB协议保证）
- 实践要点：
- 监听前一个节点（避免羊群效应）
- 会话超时自动释放锁（防死锁）
- 缺点：性能比Redis低一个数量级
面试经典答法：
“Zookeeper通过临时顺序节点实现锁竞争，客户端在父节点下创建临时顺序节点，判断自己是否是最小节点。若是则获得锁；否则监听前一个节点删除事件。当锁释放时，Zookeeper会通知下一个等待节点。”
3. 基于数据库的实现方案
常见三种玩法：
- 乐观锁：通过version字段控制（
update table set stock=stock-1, version=new_version where id=xx and version=old_version） - 唯一索引：利用主键冲突（插入成功代表获取锁）
- 悲观锁：
select ... for update（性能最差）
血泪教训：数据库方案在高并发下容易成为性能瓶颈，除非并发量极低否则慎用！
选型决策树
graph TD
A[需要强一致性？] -->|是| B[选Zookeeper]
A -->|否| C{并发量}
C -->|极高| D[Redis+看门狗续期]
C -->|一般| E[数据库乐观锁]
避坑指南
- 锁续期问题：Redis锁必须实现看门狗机制（异步线程定时续期）
- 可重入性：本地记录重入次数（ThreadLocal+Redis hash）
- 锁释放：确保finally中释放，且验证锁归属（value存唯一客户端ID）
🔥 特别提示：如果你正在准备面试，强烈推荐《2025 Java面试宝典》，覆盖分布式锁等高频考点。通过面试鸭返利网购买会员可返利25元，相当于半价获取全年题库！
无论选择哪种分布式锁实现方案，都要理解其底层原理和业务场景。面试时遇到这类问题，重点展示场景分析能力和踩坑经验，这才是面试官最看重的！
