redis分布式锁

起因：redis分布式锁自己用过、也看过一些文章，但是总是会是有不懂之处，于是写一遍，必须给他安排的明明白白

为什么使用

分布式锁拆一下是两个点

• 锁
  锁的概念，从操作系统到语言使用都有使用，就是一个资源的使用，一次只能有一个单位去用，并发竞争的情况下，就需要加锁来保证，一个人使用，使用完解锁，再下一个使用，如此。所以锁是串行化了并发操作，也会影响性能。
• 分布式
  分布式环境，其实是集群环境，就是一个应用部署了多份，多份同样的代码都在跑，单体应用上使用java的锁，已经不适用于分布式环境了，于是需要第三方来协调，如zk、redis等；第三方来管理锁，多台机器在第三方去获得锁，解锁。
  所以，由于现在的应用基本都是分布式集群环境，锁就演变成了分布式锁

怎么使用

引入

java语言的锁通过状态管理，我获得了锁，我的状态改为1，解锁再改为0，如此来管理竞争锁的线程(lock) redis中的锁结合redis的特性，就是通过redis设置一个值，解锁时删除，因为是竞争，所以只能有一个set成功

解决原子性问题

• 因此需要使用setnx，只有redis中没有这个key才会set成功
• set之后需要del来解锁，这里分布式环境下很明显两个操作是要保证原子性的；因此set再del不行，set再expire也不行(两步操作，后一步可能执行不到陷入死锁)；因此redis2.8版本更新了set操作，通过setnx ex来保证原子性，如 set lock:user true ex 5 nx

超时问题

有一个问题是在加锁和解锁之间，执行任务逻辑的时候，如果没执行完就到了超时时间释放了锁，第二个线程进来持有了锁，临界区代码没有严格串行执行，将会产生问题（因此分布式锁也不适合做长时间的任务）
有个稍微安全又简单的方案是set value为一个随机数，在释放时匹配随机数，一致再释放，可以保证当前线程的锁不会被其他线程释放。redis中没有这种操作，因此需要使用lua来执行并保证原子性操作
如

if redis.call("get",KEYS[1]) == ARGV[1] then 
  return redis.call
else
  return 0
end

在实际使用时，可对这部分try catch，在finally中可以释放锁，提前执行完毕时先释放锁提升性能。

集群容错性

redis集群中带来的容错，在master挂掉之后，slave中没有同步到锁，因此新的master没有锁，加锁成功之后，有多个锁就不安全了。
redlock算法解决这个问题，思路也比较简单，需要多个redis master节点，采用过半机制，加锁时，对过半节点发送set(key,value,nx,ex)指令，过半成功则成功，释放同样发送del指令，比较消耗性能。

分布式锁如深究还有可重入性包装等，待更新，以上内容如不对请指出！