本章学习目标:
- 理解分布式锁原理并掌握使用
- 理解乐观锁并掌握秒杀的实现
- 理解Redisson的原理
分布式锁
Watch
利用Watch实现Redis乐观锁
乐观锁基于CAS(Compare And Swap)思想(比较并替换),是不具有互斥性,不会产生锁等待而消耗资源,但是需要反复的重试,但也是因为重试的机制,能比较快的响应。因此我们可以利用redis来实现乐观锁。具体思路如下:
- 利用redis的watch功能,监控这个redisKey的状态值
- 获取redisKey的值
- 创建redis事务
- 给这个key的值+1
- 然后去执行这个事务,如果key的值被修改过则回滚,key不加1
Redis乐观锁实现秒杀
setnx
实现原理
- 共享资源互斥
- 共享资源串行化
- 单应用中使用锁:(单进程多线程)
- synchronized、ReentrantLock
- 分布式应用中使用锁:(多进程多线程)
- 分布式锁是控制分布式系统之间同步访问共享资源的一种方式。
- 利用Redis的单线程特性对共享资源进行串行化处理
实现方式
获取锁
- 方式1(使用set命令实现)–推荐
- 方式2(使用setnx命令实现) – 并发会产生问题
释放锁
- 方式1(del命令实现) – 并发
问题在于如果调用jedis.del()方法的时候,这把锁已经不属于当前客户端的时候会解除他人加的锁。那么是否真的有这种场景?
答案是肯定的,比如客户端A加锁,一段时间之后客户端A解锁,在执行jedis.del()之前,锁突然过期了,此时客户端B尝试加锁成功,然后客户端A再执行del()方法,则将客户端B的锁给解除了。
- 方式2 (redis+lua脚本实现)–推荐
存在问题
单机
无法保证高可用
主–从
无法保证数据的强一致性,在主机宕机时会造成锁的重复获得。
无法续租
超过expireTime后,不能继续使用
本质分析
CAP模型分析
- 在分布式环境下不可能满足三者共存,只能满足其中的两者共存,在分布式下P不能舍弃(舍弃P就是单机了)。
- 所以只能是CP(强一致性模型)和AP(高可用模型)。
- 分布式锁是CP模型,Redis集群是AP模型。 (base)
- Redis集群不能保证数据的随时一致性,只能保证数据的最终一致性。
为什么还可以用Redis实现分布式锁?
- 与业务有关
- 当业务不需要数据强一致性时,比如:社交场景,就可以使用Redis实现分布式锁
- 当业务必须要数据的强一致性,即不允许重复获得锁,比如金融场景(重复下单,重复转账)就不要使用
- 可以使用CP模型实现,比如:zookeeper和etcd。
Redission分布式锁的使用
- Redisson是架设在Redis基础上的一个Java驻内存数据网格(In-Memory Data Grid)。
- Redisson在基于NIO的Netty框架上,生产环境使用分布式锁。
加入jar包的依赖
<dependency>
<groupId>org.redisson</groupId>
<artifactId>redisson</artifactId>
<version>2.7.0</version>
</dependency>
配置Redisson
锁的获取和释放
业务逻辑中使用分布式锁
Redisson分布式锁的实现原理
加锁机制
如果该客户端面对的是一个redis cluster集群,他首先会根据hash节点选择一台机器。
发送lua脚本到redis服务器上,脚本如下:
lua的作用:保证这段复杂业务逻辑执行的原子性。
lua的解释:
- KEYS[1])︰加锁的key
- ARGV[1] : key的生存时间,默认为30秒
- ARGV[2]:加锁的客户端ID (UUID.randomUUID( )+"+ threadld)
第一段if判断语句,就是用"exists myLock"命令判断一下,如果你要加锁的那个锁key不存在的话,你就进行加锁。
- 如何加锁呢?很简单,用下面的命令: hset myLock
- 8743c9cO-0795-4907-87fd-6c719a6b4586:1 1
- 通过这个命令设置一个hash数据结构,这行命令执行后,会出现一个类似下面的数据结构:myLock :{“8743c9co-0795-4907-87fd-6c719a6b4586:1”:1}
- 接着会执行"pexpire myLock 30000"命令,设置myLock这个锁key的生存时间是30秒。
锁互斥机制
那么在这个时候,如果客户端2来尝试加锁,执行了同样的一段lua脚本,会咋样呢?
很简单,第一个if判断会执行“exists myLock”,发现myLock这个锁key已经存在了。
接着第二个if判断,判断一下,myLock锁key的hash数据结构中,是否包含客户端2的ID,但是明显不是的,因为那里包含的是客户端1的ID。
所以,客户端2会获取到pttl myLock返回的一个数字,这个数字代表了myLock这个锁key的剩余生存时间。比如还剩15000毫秒的生存时间。
此时客户端2会进入一个while循环,不停的尝试加锁。
自动延时机制
只要客户端1一旦加锁成功,就会启动一个watch dog看门狗,他是一个后台线程,会每隔10秒检查一下,如果客户端1还持有锁key,那么就会不断的延长锁key的生存时间。
可重入锁机制
第一个if判断肯定不成立,“exists myLock”会显示锁key已经存在了。
第二个if判断会成立,因为myLock的hash数据结构中包含的那个ID,就是客户端1的那个ID,也就是“8743c9c0-0795-4907-87fd-6c719a6b4586:1”
此时就会执行可重入加锁的逻辑,他会用:
incrby myLock
8743c9c0-0795-4907-87fd-6c71a6b4586:1 1
通过这个命令,对客户端1的加锁次数,累加1。数据结构会变成:
myLock :{“8743c9c0-0795-4907-87fd-6c719a6b4586:1”:2 }
释放锁机制
执行lua脚本如下:
– KEYS[1] :需要加锁的key,这里需要是字符串类型。
– KEYS[2] :redis消息的ChannelName,一个分布式锁对应唯一的一个channelName:
“redisson_lockchannel{” + getName() + “}”
– ARGV[1] :reids消息体,这里只需要一个字节的标记就可以,主要标记redis的key已经解锁,再结合redis的Subscribe,能唤醒其他订阅解锁消息的客户端线程申请锁。
– ARGV[2] :锁的超时时间,防止死锁
– ARGV[3] :锁的唯一标识,也就是刚才介绍的 id(UUID.randomUUID()) + “:” + threadId
如果执行lock.unlock(),就可以释放分布式锁,此时的业务逻辑也是非常简单的。
其实说白了,就是每次都对myLock数据结构中的那个加锁次数减1。
如果发现加锁次数是0了,说明这个客户端已经不再持有锁了,此时就会用:
“del myLock”命令,从redis里删除这个key。
然后呢,另外的客户端2就可以尝试完成加锁了。
分布式锁特性
- 互斥性
- 任意时刻,只能有一个客户端获取锁,不能同时有两个客户端获取到锁。
- 同一性
- 锁只能被持有该锁的客户端删除,不能由其它客户端删除。
- 可重入性
- 持有某个锁的客户端可继续对该锁加锁,实现锁的续租
- 容错性
- 锁失效后(超过生命周期)自动释放锁(key失效),其他客户端可以继续获得该锁,防止死锁
分布式锁的实际应用
数据并发竞争
利用分布式锁可以将处理串行化,前面已经讲过了。
防止库存超卖
订单1下单前会先查看库存,库存为10,所以下单5本可以成功;
订单2下单前会先查看库存,库存为10,所以下单8本可以成功;
订单1和订单2 同时操作,共下单13本,但库存只有10本,显然库存不够了,这种情况称为库存超卖。
可以采用分布式锁解决这个问题。
订单1和订单2都从Redis中获得分布式锁(setnx),谁能获得锁谁进行下单操作,这样就把订单系统下单
的顺序串行化了,就不会出现超卖的情况了。伪码如下:
注意此种方法会降低处理效率,这样不适合秒杀的场景,秒杀可以使用CAS和Redis队列的方式。
Zookeeper分布式锁的对比
- 基于Redis的set实现分布式锁
- 基于zookeeper临时节点的分布式锁
- 基于etcd实现
三者的对比,如下表
分布式集群架构中的session分离
传统的session是由tomcat自己进行维护和管理,但是对于集群或分布式环境,不同的tomcat管理各自的session,很难进行session共享,通过传统的模式进行session共享,会造成session对象在各个tomcat之间,通过网络和Io进行复制,极大的影响了系统的性能。
可以将登录成功后的Session信息,存放在Redis中,这样多个服务器(Tomcat)可以共享Session信息。
利用spring-session-data-redis(SpringSession),可以实现基于redis来实现的session分离。