企业实战之分布式锁

二、常见用法

我们也不免俗套来举个并发扣除库存的例子

我们来看一下代码

//扣除商品库存//产品id: productId//扣除数量: countpublicvoidreduce(int productId,int count){//步骤1 从数据库获得产品实体Product product = getProduct(productId);//步骤2 获得当前库存数量int stockCount = product.getStock();if(stockCount >= count){//步骤3 扣除库存   product.setStock(stockCount - count);//步骤4 把产品实体更新到数据库   productService.update(product);log.info("购买成功！") }else{log.info("库存不足，无法购买！") }}

购买场景

当前产品的库存数为10

请求A买了2个产品，那应该扣除2

请求B买了3个产品，那应该再扣除3

那最终的库存剩余为5

上面代码在分布式环境中，只要稍微流量大点，这边就会出现扣减库存不是预期的情况。原因就是

需要考虑到一些业务异常，需要把锁释放掉，加上try/finally，这个千万不要忘了

当是还是有一些问题，就是如果加锁成功后，业务没有完成。突然断电或者运维人员用kill -9命令把线程删除了；那就导致了锁一直没有释放，因为不会执行finally里面的代码了。

那怎么办呢？有经验的小伙伴应该就知道解决方案了

四、优化分布式锁

方案还是比较简单的，加个过期时间就行了

这样即使断电，过了10秒钟之后锁也会自动过期，也就是失效；别的请求就可以正常请求了

现在到了这里，就是很多公司应用分布式锁的常用方案了。小伙伴们这样就没有问题了吗？

五、问题分析

我们来看看问题出现在哪里？我们来调整一下业务代码

然后实例化

@Beanpublic Redisson redisson(){   Config config = new Config();config.useSingleServer().setAddress("redis://xxx:6379").setPassword("*").setDatabase(0);return (Redisson) Redisson.create(config);}

修改代码

用法非常简单。我们接下来分析他的原理以及源码，看看他是怎么续期的，和实现可重入的

七、源码分析

我们先来看看他的加锁流程图

加锁机制

1、线程去获取锁，获取成功: 执行lua脚本，保存数据到redis数据库。

2、线程去获取锁，获取失败:一直通过while循环尝试获取锁，获取成功后，执行lua脚本，保存数据到redis数据库。即会阻塞线程

redisson是执行的lua脚本的核心代码tryLockInnerAsync如下

redis执行lua脚本是原子性的，要么都成功，要么都失败

下面的代码就是获取锁失败，就自旋；一直尝试获取锁

续期机制

续期的业务就是上面流程图中看门狗做的，这里需要注意的是，如果要让看门狗有效果，就不要设置过期时间，如果设置了过期时间看门狗就不起作用了；看源码