深入理解分布式锁

为什么需要分布式锁

如上图,在分布式系统中,订单模块为了迎战高并发,订单服务被横向拆分,拆分成了不同的进程,就像上图,两个人同时访问订单服务,然后订单系统1和订单系统2共用一个Mysql当成数据库,经过他们查询发现仅有一件商品,所以他们自个认为都可以下单

如果不加锁限制,可能会出现库存减为负数的情况

怎么办呢?

如上图 mysql自带行级锁,可以考虑使用它的行级锁,可以保证数据的安全,但是不足之处也跟着来了,使用MySql的行级锁,系统的中压力就全部集中在mysql,那mysql就是系统吞吐量的瓶颈了,系统的吞吐量也会收到mysql的限制

可以使用分布式锁

如上图,分布式锁将系统的压力从mysql上面转移到自己身上来

什么是分布式锁

一句话,分布式锁是实现有序调度不同的进程,解决不同进程之间相互干扰的问题的技术手段

分布式锁的应具备的条件

• 在分布式系统环境下,分布式锁在同一个时间仅能被同一个进程访问
• 高可用的获取/释放锁
• 高性能的获取/释放锁
• 具备锁的重入性
• 具备锁的失效机制,防止死锁
• 具备非阻塞锁的特性,即使没有获取锁也能直接返回结果

分布式锁的实现有哪些

• mechache: 利用mechache的add命令,改命令是原子性的操作,只有在key 不存在的情况下,才能add成功,也就意味着线程拿到了锁
• Redis: 和Mechache的实现方法相似,利用redis的setnx命令,此命令同样是原子性的操作,只有在key不存在的情况下,add成功
• zookeeper利用他的顺序临时节点,来实现分布式锁和等待队列,zookeeper的设计初衷就是为了实现分布式微服务的

使用Redis实现分布式锁的思路

1. 先去redis中使用setnx(商品id,数量) 得到返回结果
2. 这里的数量无所谓,它的作用就是告诉其他服务,我加上了锁
3. 发现redis中有数量,说明已经可以加锁了
4. 发现redis中没有数据,说明已经获得到了锁
5. 解锁: 使用redis的 del商品id
6. 锁超时, 设置exprie 生命周期,如30秒, 到了指定时间,自定解锁

三个致命问题

• 非原子性操作 setnx
• 宕机
• expire

因为 setnx和expire不是原子性的,要么都成功要么都失败, 一旦出现了上面的情况,就会导致死锁出现

redis提供了原子性的操作

set ( key , value , expire)

• 误删锁 假如我们的锁的生命事件是30秒,结果我在30s内没操作完,但是锁被释放了
• jvm2拿到了锁进行操作
• jvm1 操作完成使用del,结果把jvm2 的锁删除了

解决方法, 在删除之前,判断是不是自己的锁 redis提供了原子性的操作

set ( key ,threadId, expire)

• 超时为完成任务

增加一个守护线程,当快要超时,但是任务还没执行完成,就增加锁的时间

使用ZooKeeper实现分布式锁的思路

使用ZooKeeper的临时顺序节点

系统1和系统2在执行业务逻辑之前都需要先获取到锁,然后他们就是

/Lock

释放锁后如何通知其他节点呢?

使用ZK的watcher回调机制, 让后一个节点对它的前一个临时顺序节点绑定watcher,当有事务性操作时发生回调,进而判断出自己刚才创建的节点是不是最小的,如果是说明自己拿到了锁

临时顺序节点保证了系统不会因为某台机器挂掉而出现死锁的情况

尝试加锁的方法如下:

public boolean tryLock() {
String path = LOCKNAME + "/zk_";
try {
// todo 判断父节点存在否, 不存在就先创建

// 创建临时顺序节点
currentNode.set(zooKeeper.get().create(path, new byte[0], ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL_SEQUENTIAL));
// 获取指定的根节点下所有的 临时顺序节点
List<String> names = zooKeeper.get().getChildren(LOCKNAME, false);

// 获取到的是子节点的 pathName
Collections.sort(names);
String minName = names.get(0);

if (currentNode.get().equals(LOCKNAME + "/" + minName)) {
return true;
} else {
// 监听前一个节点
int currentNodeIndex = names.indexOf(currentNode.get().substring(currentNode.get().lastIndexOf("/")+1));

// 当前节点的前一个节点的名字
String preNodeName = names.get(currentNodeIndex - 1);
// 阻塞
CountDownLatch countDownLatch = new CountDownLatch(1);

zooKeeper.get().exists(LOCKNAME + "/" + preNodeName, new Watcher() {
@Override
public void process(WatchedEvent event) {
// 监听当前节点的删除事件
if (Event.EventType.NodeDeleted.equals(event.getType())) {
countDownLatch.countDown();
}
}
});
//  在countDownLatch减完之前,会阻塞在这里等待
countDownLatch.await();
return true;
}
} catch (Exception e) {
e.printStackTrace();
}
// 按理说应该在监听的回调里面返回true,但是在这个回调里面返回不了true,现在就使用countDownLatch,回调的时候去改变countDownLatch的值
return true;
}