如何解决资源被并发访问

为什么需要分布式锁？

在单机系统中，我们可以用 synchronized、ReentrantLock 等本地锁来控制并发访问共享资源。

但在分布式系统中，多个进程/服务实例部署在不同机器上，本地锁无法跨进程生效。这时就需要一个跨进程、跨机器的协调机制 —— 分布式锁。

典型场景：
秒杀系统中扣减库存（防止超卖）
分布式任务调度（避免重复执行）
支付回调幂等处理
数据一致性更新（如用户积分、优惠券发放）

1
SET lock_key lock_value NX PX 30000

释放锁（Lua 脚本保证原子性）：

1
2
3
4
5
if redis.call("get", KEYS[1]) == ARGV[1] then
    return redis.call("del", KEYS[1])
else
    return 0
end

为什么用 Lua？因为“先判断再删除”不是原子操作，可能误删别人的锁！

RedLock 是为了解决单点 Redis 故障导致锁失效的问题。

原理简述：

举例：5 个 Redis 节点，至少 3 个加锁成功 + 总耗时 < 30ms → 加锁成功

问题	说明	解决方案
时钟漂移问题	RedLock 依赖时间判断，若节点间时钟不同步，可能导致多个客户端同时持有锁	尽量保证服务器时钟同步（NTP）
网络分区/节点故障	若多数节点宕机，锁可能失效或无法获取	适用于允许“偶尔失败”的场景，不适合强一致性系统
锁续期问题	业务执行时间 > 锁过期时间 → 锁自动释放 → 其他线程获得锁 → 数据错乱	使用“看门狗”机制自动续期（如 Redisson 的 `watchdog`）
锁误删	没有校验 value，可能删掉别人的锁	必须用 Lua 脚本校验 value 一致性

建议：生产环境推荐使用 Redisson 客户端，它内置了可重入锁、公平锁、联锁、红锁、看门狗续期等高级功能。

ZooKeeper 天然支持分布式协调，其锁机制基于：

举例：
A 创建 /lock_1，是最小 → 拿到锁
B 创建 /lock_2，监听 /lock_1
A 执行完删除 /lock_1 → B 收到通知 → 检查自己现在最小 → 拿到锁

问题	说明	解决方案
性能较低	相比 Redis，ZK 写操作较慢（需过半节点 ACK）	适合对一致性要求高、并发量不极端的场景
运维复杂	需维护 ZooKeeper 集群，配置较重	适合已有 ZK 基础设施的团队
羊群效应（Herd Effect）	大量客户端监听同一节点，一旦释放，所有客户端同时被唤醒竞争	使用“只监听前一个节点”策略避免

扩展：Curator 客户端提供了 InterProcessMutex，封装了可重入分布式锁，推荐使用。

严格来说，这不是“锁”，而是一种并发冲突检测机制，常用于更新场景。

1
2
3
UPDATE products
SET stock = stock - 1, version = version + 1
WHERE id = 100 AND version = 5;

问题	说明	解决方案
ABA 问题	version 从 5 → 6 → 5（中间被改回），可能误判	使用时间戳或递增序列号，避免回退
高并发下性能差	大量更新失败+重试，数据库压力大	限制重试次数、结合本地缓存/队列削峰
不适用“互斥执行”场景	不能阻止多个线程“同时进入临界区”，只能最后提交时检测冲突	仅适用于“最终一致性可接受”的业务

适用场景举例：商品库存扣减（配合重试）、用户资料更新、配置项修改等。

方案	一致性	性能	实现复杂度	适用场景
Redis（RedLock）	弱一致性（AP）	极高	中等	高并发、允许少量失败（如秒杀）
ZooKeeper	强一致性（CP）	中等	较高	金融、强一致、公平调度场景
数据库乐观锁	最终一致	低~中	简单	低频更新、冲突少、已有 DB 的轻量场景

选型建议：
追求性能 + 接受偶尔失败 → Redis
追求强一致 + 公平性 → ZooKeeper
不想引入中间件 + 更新不频繁 → 数据库乐观锁

分布式锁的本质，是在分布式环境下模拟“互斥访问共享资源”的能力；选型需权衡一致性、性能、复杂度；实现时务必考虑异常、超时、释放、监控等生产级细节。