Redis学习（二） —— 分布式锁

一个操作需要进行读变量，写变量两个步骤，多个相同的操作同时进行就会出现并发问题。因为读取和写入两个变量不是原子操作。

分布式锁

分布式锁本质上要实现的目标就是在 Redis 里面占一个“茅坑”，当别的进程也要来占时，发现已经有人蹲在那里了，就只好放弃或者稍后再试。

占坑一般是使用 setnx(set if not exists) 指令，只允许被一个客户端占坑。先来先占， 用完了，再调用 del 指令释放茅坑。

加锁

setnx lock:a true

释放锁

del lock:a

为了避免加锁后，中间操作出现异常，最后没有释放锁的问题，需要给锁设置一个超时时间。

setnx lock:a true
expire lock:a 5

出现另一个问题，上面的操作也有可能失败，例如设置过期时间失败。

为了解决上述的问题，Redis2.8增加了set指令的扩展参数，

set lock:a true ex 5 nx

要确保分布式锁可用，需至少要满足下面四个条件：

• 互斥性：只能一个客户端持有锁
• 不会发生死锁
• 具有容错性
• 解铃还须系铃人

超时问题

如果执行代码的时间太长，超出了锁的超时限制，就会由其他线程获得锁。会导致代码不能严格被执行。为了避免这个情况，进行加锁的执行代码尽量不要选择执行时间过长的。

可重入性

可重入性指的是线程在持有锁的情况下，再次请求加锁。

问题，为何要设计可重入这一个特性？

搞清楚几个概念：可重入锁、公平锁、非公平锁。

可重入锁：
线程1执行 synchronized A()方法，A()方法调用synchronized B()方法，当线程1获取到A方法对应的对象锁之后，再去调用B方法，就不需要重新申请锁。

公平锁：
多个线程等待锁，当锁释放后，等待该锁时间最久的（或者说最先申请锁的），应该获得锁。

非公平锁：
多个线程等待锁，不按照等待锁的时间或申请锁的先后顺序，来获得锁。

Redlock 算法

参考文档

[1]: 《Redis 深度历险：核心原理与应用实践》
[2]: 通过一个故事理解可重入锁的机制
[3]: JAVA锁机制-可重入锁,可中断锁，公平锁，读写锁，自旋锁
[4]: 80% 人不知道的 Redis 分布式锁的正确实现方式（Java 版）
[5]: Java 框架之Redis 分布式缓存
[6]: 【肥朝】面试官问我，Redis分布式锁如何续期？懵了。
[6]: Redis分布式锁的正确实现方式（Java版）

转载于:https://www.cnblogs.com/fonxian/p/10910536.html