常用的锁思想
1. 乐观锁与悲观锁
悲观锁:就是在并发环境下很悲观,每次拿数据都会认为别人要修改数据,所以每次拿数据的时候都会上锁,这样有人拿数据的时候,其他人就不能进行增删改查的操作.很多关系型数据库中用了这种锁机制.比如行锁,表锁.
乐观锁:就是并发情况下很乐观,每次拿数据的时候认为别人不会去修改,所以不会上锁,而是采用一个version字段作为版本控制,如果别人修改时version与当前数据的version不一致的时候,就进行事物回滚.ElasticSearch就是采用的这种方式.但是这种方式会导致数据脏读.
2. 死锁与活锁
死锁:比如一个人进入一个厕所,并上死锁,外面的人想要进去,但是门已经上锁进不去,也看不到这个厕所里面的内容,这就是死锁.表示一个人拿到了一个共享数据(例如一张表),其他人无法对这张表进行增删改查的操作,除非拿到了这把锁.
活锁:比如一个人进入一个厕所,上了活锁,这样外面的人可以进来,看厕所里面的内容,抽烟也好,但是坑位被占了,不能使用厕所.这就是活锁,表示一个人拿到一个共享数据(例如一张数据表),其他人可以进行查询的操作,但是不能进行增删改的操作.
分布式环境下数据不一致的场景
现在有一个商城,在网上出售一个产品名为wazi的商品,采用分布式的方式,购买商品的主要业务流程如下:
现在模拟这个订单服务部署到两台机器上,两台机器的进程同时访问product表,库存中有产品名为wazi的产品余量只有10双,但是小A和小B同一时间各下单8双,我们看看会有什么结果:
同时访问结果如下:
由于两个进程的线程同时进入购买wazi的订单业务,在获取wazi的数量时都查出来是10双,于是在后面一起完成了扣除库存的操作,导致库存数量为负数.
那么对于这种会对共享数据进行增删改的操作的业务,我们需要使用分布式锁的方式来保证高并发下的数据的一致性问题.
那么我们如果使用分布式锁需要注意哪些问题?
分布式锁需要注意的问题
- 完成订单的业务后,该锁是会释放掉的.如果不能释放掉,后面的用户就无法下订单了.(需要释放锁的操作)
- 如果用户关闭浏览器,该锁会自动释放掉.(Zookeeper中的临时节点,客户端与服务端失去连接后,会自动删除)
- 前面的锁释放后,后面的用户要能够知道锁已经被释放,并获得一把锁(Zookeeper的监听机制)
分布式锁实现的流程
本例使用的锁是悲观活锁.当一个人拿到了一个共享数据的锁后,其他人可以进行查询操作,但是不能进行增删改的操作.
分布式锁的实现流程如下:
实现主要的过程是:
- 用户进入订单购买业务,首先获取一把锁(在Zookeeper中创建一个临时的znode,其他用户获取所也要创建,如果创建失败,视为获取锁失败,并阻塞当前线程)
- 用户订单购买的业务走完后,主动释放锁(在Zookeeper中删除这个znode)
- ZK客户端监听到对应的znode被删除后,主动唤醒后面的线程主动获取锁(CountDownLatch + Zookeeper的Watch机制)
使用Apache Curator实现分布式锁的主要代码:
创建一个类DistributedLock,这个类有释放锁,创建锁和监听特定Znode节点的方法.
- 初始化Curator客户端:
- 获取分布式锁
- 释放分布式锁
- 在订单购买业务中添加分布式锁和释放分布式锁
测试
当加上分布式锁之后,我们在使用相同场景进行测试,
现在模拟这个订单服务部署到两台机器上,两台机器的进程同时访问product表,库存中有产品名为wazi的产品余量只有10双,但是小A和小B同一时间各下单8双,我们看看会有什么结果:
购买前:
并发访问后:
从日志中可以看出,当第一个人进入到订单购买程序后,后面的用户则进行了线程等待的状态,直到前面的用户购买wazi成功了之后,后面的用户才进入到订单购买业务中来,最终一开始的人购买成功,后面的用户购买失败.
源码位置
- github地址: https://github.com/lilike/chawuzhi.git
