redis—分布式锁

1.基于数据库的分布式锁

基于数据库实现的分布式锁_朱小厮的博客-CSDN博客_数据库分布式锁

2.基于Redis的分布式锁

redis用的很多，面试时也会问一些redis的关键点，下面小结了一些redis锁的知识点：

1.要使用分布式锁是因为多个服务器

2.要设置有效时间，这是基于如果逻辑执行到中间出现异常，没有执行del释放锁(比如服务的宕机了)，就会导致死锁，所以要使用expire设置有效时间。

3.超时时间不能设置过大，也不能设置过小：

设置过小，会导致第一个请求还没有执行完，锁就释放了，第二个请求又过来了，此时同时两个请求进行操作。

设置过大，会导致死锁，加锁后，逻辑执行到中间异常，没有执行del释放锁，导致较长时间无法获取锁。

4.setnx和expire指令是可以同时执行的。setnx命令保证了互斥性，在任意时刻，只有一个客户端能持有锁。

5.第一个线程执行逻辑的时间过长，超过了锁的超时限制，此时第二个线程就会获取到锁，第一个线程执行完逻辑会把锁释放，第三个线程会在第二个线程执行代码逻辑时，重新获取锁。解决办法是将value设置一个随机值，释放锁前先匹配随机值是否一致。(说明这里去了随机值，还要释放，好的方式是获取mac地址+线程号作为value的值)

注意匹配value和删除key不是原子操作，此时需要lua脚本处理。一种极端的情况，如果第一个线程加锁，准备解锁，匹配了value值，还没来得及删除key时，锁超时，自动释放了，第二个线程加了锁，此时第一个线程删除key就是把第二个线程的锁删除了

6.可重入性是通过ThreadLocal来实现的。

7.还有一种极端情况，如果Redis是主从架构，此时如果对主节点写入后，主节点挂了，并且从节点没有来得及同步写入的数据，此时就加锁失败。此时可以考虑RedLock，redlock使用大多数机制，加锁时会向半节点发送set指令，只要过半节点set成功，就认为加锁成功。释放锁，需要向所有节点发送del指令。缺点比单实例Redis性能会下降。因为redis满足CAP理论中的A(可用性)和P(分区容错)，此时可以考虑Zookeeper

加锁示例(最精简版本)：

 解锁示例(最精简版本)：

Redission源码解析：

 先看tryLock的方法：

 参考：

带你研究Redis分布式锁，源码走起

分布式锁的正确实现原理演化历程与 Redisson 实战总结 (qq.com)

解锁redis锁的正确姿势 - 轩脉刃 - 博客园 (cnblogs.com)

分布式锁用 Redis 还是 Zookeeper？看完你就明白了！！_程序员小乐的博客-CSDN博客

Redission初见_哔哩哔哩_bilibili

Redis分布式锁的原理以及如何续期_击水三千里的博客-CSDN博客_redis分布式锁续期