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

时间 2019-12-14

原文原文链接

一个操做须要进行读变量，写变量两个步骤，多个相同的操做同时进行就会出现并发问题。由于读取和写入两个变量不是原子操做。html

分布式锁

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

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

加锁分布式

setnx lock:a true

释放锁线程

del lock:a

为了不加锁后，中间操做出现异常，最后没有释放锁的问题，须要给锁设置一个超时时间。设计

setnx lock:a true
expire lock:a 5

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

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

set lock:a true ex 5 nx

若是执行代码的时间太长，超出了锁的超时限制，就会由其余线程得到锁。会致使代码不能严格被执行。为了不这个状况，进行加锁的执行代码尽可能不要选择执行时间过长的。对象

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

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

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

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

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

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