一、分布式锁特性
### --- 互斥性
~~~ 任意时刻,只能有一个客户端获取锁,不能同时有两个客户端获取到锁。
~~~ Redis : setnx set key value NX 如果key存在就不设置
### --- 同一性
~~~ 锁只能被持有该锁的客户端删除,不能由其它客户端删除。
~~~ Redis : lua 实现原子性
### --- 可重入性
~~~ 持有某个锁的客户端可继续对该锁加锁,实现锁的续租
### --- 容错性
~~~ 锁失效后(超过生命周期)自动释放锁(key失效),其他客户端可以继续获得该锁,防止死锁
~~~ expire 设置超时时间
set key value NX PX
二、分布式锁的实际应用
### --- 分布式锁的实际应用
~~~ 数据并发竞争
### --- 利用分布式锁+时间戳可以将处理串行化,前面已经讲过了。
~~~ 防止库存超卖
![](https://img-blog.csdnimg.cn/img_convert/b4de22b2dd68fa9f0187ef66b827eb78.png)
~~~ 订单1下单前会先查看库存,库存为10,所以下单5本可以成功;
~~~ 订单2下单前会先查看库存,库存为10,所以下单8本可以成功;
~~~ 订单1和订单2 同时操作,共下单13本,但库存只有10本,
~~~ 显然库存不够了,这种情况称为库存超卖。
~~~ 可以采用分布式锁解决这个问题。
![](https://img-blog.csdnimg.cn/img_convert/56431cef28b47dcb4c05a4c704c67365.png)
~~~ # 订单1和订单2都从Redis中获得分布式锁(setnx),
~~~ 谁能获得锁谁进行下单操作,这样就把订单系统下单的顺序串行化了,
~~~ 就不会出现超卖的情况了。伪码如下:
~~~ 获得分布式锁
~~~ 取得库存
~~~ 如果大于下单数
~~~ 下单
~~~ 更改库存
~~~ 释放锁
~~~ # 注意此种方法会降低处理效率,这样不适合秒杀的场景,秒杀可以使用CAS和Redis队列的方式。
~~~ # 加锁并设置有效期
if(redis.lock("RDL",200)){
//判断库存
if (orderNum<getCount()){
//加锁成功 ,可以下单
order(5);
updateCount(5)
//释放锁
redis,unlock("RDL");
}
}