使用Zookeeper实现分布式锁(二)

常用的锁思想

1. 乐观锁与悲观锁

悲观锁:就是在并发环境下很悲观,每次拿数据都会认为别人要修改数据,所以每次拿数据的时候都会上锁,这样有人拿数据的时候,其他人就不能进行增删改查的操作.很多关系型数据库中用了这种锁机制.比如行锁,表锁.

乐观锁:就是并发情况下很乐观,每次拿数据的时候认为别人不会去修改,所以不会上锁,而是采用一个version字段作为版本控制,如果别人修改时version与当前数据的version不一致的时候,就进行事物回滚.ElasticSearch就是采用的这种方式.但是这种方式会导致数据脏读.

2. 死锁与活锁

死锁:比如一个人进入一个厕所,并上死锁,外面的人想要进去,但是门已经上锁进不去,也看不到这个厕所里面的内容,这就是死锁.表示一个人拿到了一个共享数据(例如一张表),其他人无法对这张表进行增删改查的操作,除非拿到了这把锁.

活锁:比如一个人进入一个厕所,上了活锁,这样外面的人可以进来,看厕所里面的内容,抽烟也好,但是坑位被占了,不能使用厕所.这就是活锁,表示一个人拿到一个共享数据(例如一张数据表),其他人可以进行查询的操作,但是不能进行增删改的操作.

分布式环境下数据不一致的场景

现在有一个商城,在网上出售一个产品名为wazi的商品,采用分布式的方式,购买商品的主要业务流程如下:

2.png

现在模拟这个订单服务部署到两台机器上,两台机器的进程同时访问product表,库存中有产品名为wazi的产品余量只有10双,但是小A和小B同一时间各下单8双,我们看看会有什么结果:

3.png

同时访问结果如下:

4.png

由于两个进程的线程同时进入购买wazi的订单业务,在获取wazi的数量时都查出来是10双,于是在后面一起完成了扣除库存的操作,导致库存数量为负数.

那么对于这种会对共享数据进行增删改的操作的业务,我们需要使用分布式锁的方式来保证高并发下的数据的一致性问题.

那么我们如果使用分布式锁需要注意哪些问题?

分布式锁需要注意的问题

完成订单的业务后,该锁是会释放掉的.如果不能释放掉,后面的用户就无法下订单了.(需要释放锁的操作)
如果用户关闭浏览器,该锁会自动释放掉.(Zookeeper中的临时节点,客户端与服务端失去连接后,会自动删除)
前面的锁释放后,后面的用户要能够知道锁已经被释放,并获得一把锁(Zookeeper的监听机制)

分布式锁实现的流程

本例使用的锁是悲观活锁.当一个人拿到了一个共享数据的锁后,其他人可以进行查询操作,但是不能进行增删改的操作.

分布式锁的实现流程如下:

1.png

实现主要的过程是:

用户进入订单购买业务,首先获取一把锁(在Zookeeper中创建一个临时的znode,其他用户获取所也要创建,如果创建失败,视为获取锁失败,并阻塞当前线程)

用户订单购买的业务走完后,主动释放锁(在Zookeeper中删除这个znode)

ZK客户端监听到对应的znode被删除后,主动唤醒后面的线程主动获取锁(CountDownLatch + Zookeeper的Watch机制)

使用Apache Curator实现分布式锁的主要代码:

创建一个类DistributedLock,这个类有释放锁,创建锁和监听特定Znode节点的方法.

初始化Curator客户端:

5.png

获取分布式锁

6.png

释放分布式锁

7.png

在订单购买业务中添加分布式锁和释放分布式锁

9.png

测试

当加上分布式锁之后,我们在使用相同场景进行测试,

购买前:

10.png

并发访问后:

11.png

从日志中可以看出,当第一个人进入到订单购买程序后,后面的用户则进行了线程等待的状态,直到前面的用户购买wazi成功了之后,后面的用户才进入到订单购买业务中来,最终一开始的人购买成功,后面的用户购买失败.

源码位置

github地址: https://github.com/lilike/chawuzhi.git