技术点拆解：分布式锁（Redis + Lua）

以下是对该技术点的详细拆解，帮助你应对面试中的深度追问：

1. 核心实现原理

技术要点：
• 分布式锁目的：在分布式系统中保证同一时刻只有一个客户端能执行关键操作（如扣减库存）。
• Redis实现方案：
• Lua脚本保证原子性：将SETNX（设置锁）、EXPIRE（设置过期时间）合并为一个原子操作。
• 锁标识唯一性：使用UUID作为锁的Value，防止误删其他客户端的锁。
• 过期时间：根据业务预估最大执行时间设置（如10秒），避免死锁。

代码示例： 

-- Lua脚本：获取锁（原子操作）
local key = KEYS[1]
local value = ARGV[1]
local expire = ARGV[2]
local result = redis.call('SET', key, value, 'NX', 'PX', expire)
return result

2. 高频面试问题与回答示例

Q1：为什么用Lua脚本？直接用SETNX+EXPIRE不行吗？

回答示例：

“直接使用SETNX和EXPIRE是非原子操作。如果在执行SETNX后服务宕机，锁将永久存在，导致死锁。Lua脚本可以保证这两个命令的原子性，避免中间状态不一致。”

扩展追问：
• Redis事务（MULTI/EXEC）能否替代Lua脚本？

“不能。Redis事务只是将命令打包执行，不保证原子性（如执行EXEC前发生错误，已执行的命令不会回滚）。而Lua脚本是天然原子性的。”

Q2：锁的过期时间设置多久？如何续期？

回答示例：

“过期时间根据业务逻辑的最大执行时间估算（如库存扣减操作平均耗时2秒，设置10秒）。但极端情况下，若业务未执行完锁已过期，可能导致并发问题。项目中未实现续期，但更优方案是使用Redisson的watchDog机制（后台线程定期检测锁是否持有并自动续期）。”

优化方案：
• Redisson看门狗：默认每隔10秒检查锁是否仍被当前线程持有，若持有则续期30秒。

Q3：如何避免锁误删（删了其他客户端的锁）？

回答示例：

“释放锁时需验证Value是否与当前线程的标识一致。例如，线程A获取锁时存入UUID，释放时先GET锁的Value，若匹配再删除。但GET和DEL操作非原子，可能被其他线程插入操作，因此仍需用Lua脚本保证原子性。”

代码示例： 

-- Lua脚本：释放锁（原子操作）
if redis.call("GET", KEYS[1]) == ARGV[1] then
    return redis.call("DEL", KEYS[1])
else
    return 0
end
Q4：Redis分布式锁在CAP中的权衡？

回答示例：

“Redis是AP系统（高可用+分区容忍），在网络分区时可能同时出现多个客户端持有锁（脑裂问题）。若对强一致性要求极高，可用ZooKeeper（CP系统，通过临时有序节点和Watcher机制保证锁唯一性）。”

对比方案：
• ZooKeeper锁：
• 优点：强一致、无过期时间、自动释放（连接断开后节点自动删除）。
• 缺点：性能低于Redis，写操作需集群半数以上节点确认。

Q5：是否会出现锁重入问题（同一线程多次获取锁）？

回答示例：

“当前方案不支持可重入锁。若线程A已持有锁，再次尝试获取会失败。可通过在Value中记录线程标识和重入次数（如uuid:count），每次重入时增加计数，释放时减少计数，归零后删除锁。”

代码示例： 

-- Lua脚本：可重入锁获取
local key = KEYS[1]
local threadId = ARGV[1]
local count = redis.call('HGET', key, 'count') or 0
if count == 0 then
    redis.call('HSET', key, 'count', 1)
    redis.call('EXPIRE', key, 10)
    return 1
else
    redis.call('HINCRBY', key, 'count', 1)
    return 1
end

3. 项目中的优化与反思

• 优化点：
• 使用Hash结构存储锁的标识和重入次数（如果支持可重入）。
• 引入Redisson替代手动实现，简化代码并解决续期问题。
• 反思点：
• 初期未考虑锁续期，极端情况下业务执行时间超过锁过期时间，导致并发问题。
• 未实现可重入锁，后续优化中通过记录线程标识和计数器解决。

4. 模拟追问链

  1. 问：Redis主从切换时，锁可能丢失，如何解决？
    答：使用RedLock算法（向多个独立Redis实例申请锁，半数以上成功才算获取锁），但实现复杂且争议较大（社区有脑裂风险讨论）。
  2. 问：如何监控分布式锁的健康状态？
    答：通过Redis的INFO命令监控锁的过期时间、获取失败率，或集成Prometheus+Grafana报警。
  3. 问：高并发下锁竞争激烈，如何优化？
    答：
    • 减少锁粒度（如按商品ID分锁）。
    • 结合乐观锁（如库存扣减使用CAS：UPDATE stock SET count=count-1 WHERE id=1 AND count>0）。

总结

• 核心知识点：Lua脚本原子性、锁续期与误删防范、Redis与ZooKeeper锁对比。
• 回答技巧：
• 结合项目场景：说明为什么选择Redis而非其他方案（如性能要求高、已有Redis基础设施）。
• 主动暴露权衡：承认当前方案的不足（如无续期机制），并说明后续优化方向。
• 量化结果：例如“引入分布式锁后，超卖率从5%降至0.1%”。

最后一句话：
“在实现分布式锁时，我重点关注了操作的原子性和锁的安全性，通过Lua脚本+唯一标识避免了锁误删，并通过压力测试验证了方案的可靠性。后续计划引入Redisson优化锁续期机制，进一步提升系统稳定性。”

掌握这些知识点后，你可以在面试中自信应对分布式锁相关的任何挑战！ 🚀