在分布式系统中多个服务实例共享资源时需通过分布式锁保证操作原子性Redis凭借高性能、高可用特性成为实现分布式锁的主流方案。本文从核心原理、关键实现细节、常见问题及面试高频考点展开解析帮助理解Redis分布式锁的设计逻辑与实践要点。 在后端面试中Redis分布式锁堪称“必考题之王”——从初级工程师到架构师几乎每个技术面都会被追问。不少候选人能说出SET NX EX命令却栽在“脑裂怎么解决”“锁过期了怎么办”上错失心仪offer。今天这篇文章帮你吃透Redis分布式锁的核心逻辑、高频考点和避坑要点让你面对追问时游刃有余。一、先搞懂Redis分布式锁到底用来解决什么问题在单体应用里用Java的synchronized或ReentrantLock就能保证线程安全但到了分布式系统多个服务实例共享同一资源比如库存扣减、订单创建本地锁完全失效——这时候就需要“分布式锁”让多个服务像排队一样同一时间只有一个能操作资源。Redis凭借高性能单机QPS万级、支持原子操作的特性成为实现分布式锁的首选方案。它的核心逻辑特别简单用一个唯一的Redis key当“锁”谁能成功创建这个key谁就拿到锁操作完资源后再删除这个key释放锁。篇幅限制下面就只能给大家展示小册部分内容了。整理了一份核心面试笔记包括了Java面试、Spring、JVM、MyBatis、Redis、MySQL、并发编程、微服务、Linux、Springboot、SpringCloud、MQ、Kafka 面试专题以上笔记或面试技巧 https://github.com/encode-studio-fe/natural_traffic/wiki/scan_material3二、面试必问的3个核心考点答案直接背考点1最基础的加锁命令为什么必须用SET NX EX很多面试候选人会说“用SETNX加锁再用EXPIRE设过期时间”但这恰恰是第一个坑因为SETNX和EXPIRE是两步操作不是原子的——如果SETNX成功后服务突然宕机EXPIRE没执行这个锁就会永久存在导致其他服务永远拿不到锁死锁。正确答案用Redis 2.6.12以上版本支持的SET命令多参数组合把“加锁设过期时间”变成原子操作# key锁名称如lock:stockvalue唯一标识IP线程ID # NX仅当key不存在时创建EX设10秒过期时间 SET lock:stock 192.168.1.100:thread1 NX EX 10这句话一定要记牢NX保证互斥同一时间只有一个人能加锁EX避免死锁服务宕机后锁会自动释放原子操作解决“两步走”的风险。考点2释放锁时直接DEL命令行吗绝对不行这是第二个高频坑。比如服务A加的锁过期了Redis自动删除了key这时候服务B成功加锁开始执行业务但服务A恢复后直接用DEL命令删除了锁——相当于服务A误删了服务B的锁导致多个服务同时操作资源锁彻底失效。正确答案释放锁必须先“校验身份”再“删除锁”而且这两步要原子化。解决方案是用Lua脚本# 先判断锁的持有者是不是自己对比value是就删除 if redis.call(GET, KEYS[1]) ARGV[1] then return redis.call(DEL, KEYS[1]) else return 0 end原理Redis执行Lua脚本时会阻塞其他命令确保“校验删除”不会被打断彻底避免误删他人锁的问题。考点3Redis主从架构下分布式锁有什么风险怎么解决这是区分候选人“基础款”和“进阶款”的关键问题90%的初级工程师答不上来。风险点Redis主从同步是异步的。比如服务A在主节点加锁成功但主节点还没把这个锁同步到从节点就宕机了从节点升级成新主节点后因为没同步到锁信息服务B就能成功加锁——这时候出现“两把锁”也就是“脑裂”问题。正确答案用Redlock红锁算法。核心逻辑是1.部署至少3个独立的Redis节点无主从关系各自独立2.加锁时同时向这3个节点发送SET NX EX命令3.只有当超过半数节点比如3个节点中至少2个 加锁成功才认为整体加锁成功4.释放锁时向所有节点发送释放命令。原理通过“多节点投票”即使某个节点宕机只要多数节点正常就能保证锁的唯一性降低脑裂风险。生产中不用自己实现直接用Redisson组件的RedissonRedLock即可。篇幅限制下面就只能给大家展示小册部分内容了。整理了一份核心面试笔记包括了Java面试、Spring、JVM、MyBatis、Redis、MySQL、并发编程、微服务、Linux、Springboot、SpringCloud、MQ、Kafka 面试专题笔记或面试技巧 https://github.com/encode-studio-fe/natural_traffic/wiki/scan_material3三、实战避坑2个生产环境常见问题面试提一句加分问题1业务执行时间超过锁过期时间怎么办 比如锁设了10秒过期但业务需要20秒才能执行完——锁过期后其他服务会加锁导致数据冲突。 解决方案用“锁续约”机制比如Redisson的“看门狗”线程。业务执行过程中看门狗线程每隔3秒检查一次如果当前服务还持有锁就把锁的过期时间延长到10秒直到业务执行完再释放锁。问题2分布式锁支持重入吗怎么实现 基础版的SET NX EX不支持重入同一线程多次加锁会失败比如递归调用场景。 解决方案用可重入锁设计。在value中存储“持有者标识重入次数”比如value192.168.1.100:thread1:2最后一位是重入次数。加锁时• 如果是新线程执行SET NX EX• 如果是当前持有锁的线程直接把重入次数1 释放时• 重入次数-1当次数减到0时再执行DEL命令删除锁。 生产中直接用Redisson的RLock开箱即用支持重入。四、总结面试应答框架直接套用当面试官问“Redis如何实现分布式锁”时别上来就说命令按这个逻辑答条理清晰还加分1.先讲核心场景分布式系统共享资源需互斥Redis因高性能成为首选2.再讲基础实现用SET NX EX原子加锁Lua脚本原子释放避免死锁和误删3.然后讲进阶风险主从架构的脑裂问题用Redlock算法解决4.最后提实战优化锁续约解决过期问题可重入锁支持递归场景生产用Redisson组件