redis分布式锁

问题产生

如果有一个操作为修改用户信息，且修改前需要先读取用户信息（这种修改会依赖读取出的信息）。此时如果有并发，那么由于“读取”和“修改”这两个操作不是原子操作，可能最终得到的结果并不是我们想得到的。

分布式锁就是为了解决并发线程相互影响而得不到正确值的场景。

分布式锁

redis的分布式锁是使用setnx(set if not exists)指令来占用资源，等使用完后再使用del指令来释放资源。其过程如下：

> setnx lock:resource true  #这里的lock:resource是一个key
OK
...do something critical ...
> del lock:resource
(integer) 1

改进

如果单纯是这样的话，在用del释放资源之前线程down掉或者出现什么异常而终止，这样资源一直得不到释放，即死锁诞生。
为了防止这样的死锁产生，可以给锁添加有效时间来解决，具体过程如下：

> setnx lock:resource true  
OK
> expire lock:resource 5
...do something critical ...
> del lock:resource
(integer) 1

但是这样并不是完美的，因为当setnx与expire之间可能发生线程down掉，此时已然会产生死锁。会发生这种情况的根本原因是setnx和expire是两条指令，不是原子操作。如果我们将setnx和expire指令用事务包起来，也是不能解决问题，这是由于expire的操作是由setnx的结果决定是否执行的，如果没占到资源，就不用设置过期时间了，而事务是逐条执行，不能表达这种因果关系，故事务并不能解决这个问题。
为了解决这个问题Redis加入了set指令的扩展参数，是setnx和expire可以在一起执行，具体过程如下：

> set lock:resource true ex 5 nx
OK
... do something ...
> del lock:resource

再次改进

这样的分布式锁就完美了么？并不是，当do something的时间过长，大于expire的过期时间时，会出现线程未执行完毕，占用的资源已过期，那么其他线程也会来使用该资源，那么最开始并发造成的问题将重现。
此时如果出现这种情况，假设有n个进程，只有第一个线程过长，导致资源占用过期，那么后面的进程可能进入，第一个进程操作完后将释放资源，此时已经不是自己占用的资源，可能会释放其他进程占用的资源，这样导致其他进程又可以进入。最终的效果将和没有加锁的效果一样。为了避免这种情况的发生可以使用相对安全的方式，具体过程如下：

tag = random.nextint()
if redis.set(key, tag, nx = True, ex = 5):
	do_something()
	redis.delifequals(key, tag)   #相等即删除。redis没有这种操作，只能先匹配值，然后del,想要其成为原子操作，可以使用Lua脚本来处理。

这样可以避免上面的情况，只是超长线程和随后进程会有所影响，所以是相对安全的方式。