Redis应用之二分布式锁2
一、前言
前一篇 Redis应用之二分布式锁 我们介绍了使用SETNX来实现分布式锁，并且还遗留了一个Bug，今天我们对代码进行优化，然后介绍一下Redisson以及数据库的乐观锁悲观锁怎么用。
二、SetNX分布式锁优化后代码
RedisService.java
InventoryMgrImpl.java
将代码部署在两台机器，库存设置为10000， set "inventory:9321785256118" 10000，然后Jemter创建两个线程组，每个线程组起500个线程，循环执行10次，结果库存值为0，没有产生并发问题。注（这里每一次调用扣减一个库存）。
注意点
1、设置锁的超时时间，超时时间不能设置太短，一定要比业务代码执行耗时最长的时间再大一些，一般设置为3秒差不多，上一篇文章用了Redis分布式锁还产生问题的原因就是因为超时时间设置太短造成的，业务代码还未执行完，锁就失效被另外一个线程持有然后在并发量大的情况就产生问题了。另外老版本Redis的SetNX好像是不能设置超时时间，这个就必须自己去控制超时以避免死锁。
2、代码中当获取锁失败立即重新去获取这个会对redis造成冲击，可以加入适当的休眠时间。
三、使用Redisson实现Redis分布式锁
Redisson是一个基于Redis扩展库，提供了很多具有分布式环境特性的常用工具类，我们这里用来使用它分布式锁机制。
1、加入依赖包
2、配置类
3、代码中获取锁
用100个线程两台机器压测，未产生并发问题。
注：高版本JDK（比如JDK17）Redisson运行时报错，原因未确认。
以上不管是自己直接调用SetNX，还是用Redisson做分布式锁都是基于单台Redis的，如果是集群Redis会更复杂一些。
四、数据库锁
数据库锁也分为乐观锁和悲观锁，这种方案在传统软件公司会采用比较多一些，互联网公司一般不太采用数据库的特性去做事情，主要是数据库负载相对来讲比较大，会尽量避免。
1、乐观锁
认为数据一般不会发生冲突，在数据提交更新时才会去检查数据是否冲突，如果冲突不执行返回错误。
具体实现：通过给表加一个version字段来实现，当读取数据时，将version字段的值一起读出，数据每更新一次，对此version值加一。当我们提交更新的时候，判断当前version与开始取出来的版本值大小是否相等，如果相等，则予以更新，否则认为出现并发问题不更新数据，让用户重新操作。
创建库存表
SpringBoot整合JDBC
InventoryManagerDB.java
不用数据库锁，Jmeter开启两组线程，每组1个线程，循环500次，最终库存数据是208，肯定会产生并发问题。
代码中加上乐观锁
1、数据库增加version字段
2、InventoryManagerDB.java
Jmeter开启两组线程，每组1个线程，循环500次，最终库存数如下
这说明有307次变更库存是失败的，693次变更成功，但没有发生并发问题，因为直接告诉用户失败了或者让用户采用重试机制。
2、悲观锁
对数据的冲突采取悲观的态度，也就是假设数据肯定会冲突，所以在数据开始读取的时候，就把数据锁定住，此时当其他事务如果要更新此条记录就会因为不能获得锁而阻塞。
注意：这里查询的时候用主键然后加上for update锁定这条记录，并且该方法要加上@Transactional事务控制，如果不是使用主键可能就把整张表锁住了。
Jmeter开启两组线程，每组50个线程，循环10次，最终库存数据是0，未产生并发问题。