分布式系统 高并发环境：看一眼就能懂的“分布式锁”原理

🔥 分布式系统 | 高并发环境：看一眼就能懂的"分布式锁"原理

📰 最新消息（2025-08）
某知名电商平台因分布式锁失效导致"618大促"期间库存超卖，损失超千万！技术团队紧急修复后承认："锁没用好，等于没锁。"这再次证明——分布式锁，真不是随便加个synchronized就能搞定的！

💡 为什么需要分布式锁？

想象一下双11秒杀场景：

• 100万人同时抢1万件商品
• 如果只用单机锁（比如Java的synchronized），其他服务器根本不知道你锁了
• 结果：库存变成-99万件（老板脸都绿了🌿）

分布式锁的核心目标：让多个机器上的进程像单机一样有序操作共享资源

🧀 分布式锁的三大刚需

1. 互斥性：同一时刻只有一个客户端能持有锁（别让大家一起改数据）
2. 防死锁：持有锁的客户端挂了，锁必须能自动释放（别让系统卡死）
3. 高可用：锁服务不能单点故障（别锁服务挂了整个系统瘫痪）

🛠️ 主流实现方案对比

Redis实现（最常用）

原理：用SET key value NX PX 30000命令（原子性操作）

• NX：只有key不存在时才设置
• PX 30000：30秒后自动过期

// 伪代码示例
boolean locked = redis.set("lock:order_123", "client1", "NX", "PX", 30000);
if (locked) {
    try {
        // 处理业务
    } finally {
        redis.del("lock:order_123"); // 释放锁
    }
}

😱 坑点：

• 如果业务执行超过30秒，锁自动释放，其他客户端可能拿到锁
• 解决方案：启动守护线程定期续期（Redisson的"看门狗"机制）

Zookeeper实现（强一致性）

原理：创建临时有序节点

• 所有客户端抢着创建/lock/order_123_节点
• 序号最小的获得锁，其他监听前一个节点

优势：

• 天然解决锁释放问题（客户端断开连接，临时节点自动删除）
• 严格有序，适合需要公平锁的场景

代价：性能比Redis差，需要维护ZK集群

数据库实现（不推荐但简单）

-- 建表
CREATE TABLE distributed_lock (
    id INT PRIMARY KEY,
    resource_name VARCHAR(64) UNIQUE,
    client_id VARCHAR(64),
    expire_time DATETIME
);
-- 获取锁（利用唯一约束）
INSERT INTO distributed_lock VALUES (1, 'order_123', 'client1', NOW() + 30 SECOND);

🤕 缺点：数据库压力大，性能差，死锁检测复杂

🚨 必须避开的四大天坑

1. 误删锁：A的锁被B删了

   解决：锁value存客户端ID，删除时校验

2. 锁过期：业务没执行完锁就没了

   解决：自动续期 or 合理设置超时

   

3. 脑裂问题：Redis主从切换导致锁失效

   解决：RedLock算法（争议大，谨慎使用）

4. 锁重入：同一个线程多次获取锁

   解决：像Redisson那样维护锁计数器

🌟 最佳实践建议

1. 能用单机锁就别用分布式锁（很多场景其实不需要）
2. 永远设置超时时间（防止死锁）
3. 释放锁要放finally块（避免异常导致锁泄漏）
4. 考虑用现成框架（如Redisson、Curator）

🤔 思考题

如果Redis和ZK同时挂了，你的系统还能正常处理订单吗？
（提示：这引出了更复杂的"分布式共识算法"话题...）

下次我们聊聊如何用Raft协议让系统在故障时依然坚挺！ 🚀