摘要：在微服务架构中，分布式锁就像一场“抢椅子”游戏的“裁判”，确保在分布式环境下，同一时刻只有一个服务实例可以执行某个关键操作，避免数据不一致的问题。
在微服务架构中，分布式锁就像一场“抢椅子”游戏的“裁判”，确保在分布式环境下，同一时刻只有一个服务实例可以执行某个关键操作，避免数据不一致的问题。
1. 基于Redis的分布式锁（Redisson）
Redisson是一个基于Redis的java客户端，它提供了丰富的分布式锁实现，包括可重入锁、公平锁、读写锁等。
- 原理：利用Redis的`SETNX`（SET if Not eXists）命令，结合`EXPIRE`设置过期时间，确保锁的互斥性和避免死锁。
- 生活比喻：想象一个“共享充电宝”的场景，Redisson就像一个“智能锁”，只有你成功“扫码”（获取锁）后，才能取出充电宝（执行操作），并且这个“智能锁”还会自动“计时”（过期时间），防止你“霸占”充电宝不还（死锁）。
- 代码示例：
```java
Config config = new Config;
config.useSingleServer.setAddress("redis://127.0.0.1:6379");
RedissonClient redisson = Redisson.create(config);
RLock lock = redisson.getLock("myLock");
try {
// 尝试加锁，最多等待100秒，上锁以后10秒自动解锁
boolean isLocked = lock.tryLock(100, 10, TimeUnit.SECONDS);
if (isLocked) {
// 执行业务逻辑
System.out.println("获取锁成功，执行业务逻辑");
}
} catch (InterruptedException e) {
e.printStackTrace;
} finally {
// 解锁
lock.unlock;
System.out.println("释放锁");
}
```
2. 基于ZooKeeper的分布式锁（Curator）
Curator是Netflix开源的一个ZooKeeper客户端框架，它提供了丰富的分布式锁实现，包括可重入锁、读写锁等。
- 原理：利用ZooKeeper的临时有序节点（EPHEMERAL_SEQUENTIAL）特性，确保锁的互斥性和可重入性。
- 生活比喻：想象一个“排队挂号”的场景，ZooKeeper就像一个“挂号系统”，每个请求都会得到一个“序号”（有序节点），序号最小的请求可以“看病”（获取锁），如果“病人”中途离开（服务实例宕机），“挂号系统”会自动“销号”（临时节点消失），确保“叫号”的公平性。
- 代码示例：
```java
RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000, 3);
CuratorFramework client = CuratorFrameworkFactory.newClient("127.0.0.1:2181", retryPolicy);
client.start;
InterProcessMutex lock = new InterProcessMutex(client, "/myLock");
try {
// 获取锁
lock.acquire;
} catch (Exception e) {
} finally {
// 释放锁
try {
lock.release;
}
}
```
3. 基于数据库的分布式锁
- 原理：利用数据库的“唯一索引”或“悲观锁（SELECT ... FOR UPDATE）”特性，确保锁的互斥性。
- 生活比喻：想象一个“火车票抢购”的场景，数据库就像一个“售票系统”，同一时刻只允许一个“窗口”（服务实例）卖出同一张票（执行操作），其他“窗口”只能“等待”或“返回失败”。
- 代码示例（以MySQL为例）：
```sql
-- 获取锁
SELECT * FROM distributed_lock WHERE lock_name = 'myLock' FOR UPDATE;
-- 执行业务逻辑
-- 释放锁（事务提交或回滚）
```
总结：
分布式锁，就是微服务架构中，确保“同一时刻，只有一个服务实例可以执行关键操作”的“裁判”。Redisson（基于Redis）就像一个“智能锁”，Curator（基于ZooKeeper）就像一个“挂号系统”，而数据库锁则像一个“售票系统”。选择哪种实现，取决于你的业务场景、性能要求和运维复杂度。
来源：程序员讲故事聊生活