分布式锁的场景以及实现方案_redis分布式锁使用场景

1.创建锁表，利用唯一性约束,获取锁时插入数据库。

2.释放锁时,删除数据

优点:容易理解,实现简单

缺点:性能比较差,适合并发不高的场景

1.主要设置锁的超时时间,避免死锁
2.如果锁过期了事情没干完-使用多线程（守护线程）延长过期
3.为了保证原子性操作,实现的时候采用Redisson(API实现比较简单/源码中加锁/释放锁操作都是用 Lua 脚本完成的，封装的非常完善，开箱即用)

优点:redis的性能很高，可以支撑高并发的获取、释放锁操作。

缺点:集群环境下,主节点宕机时,两个线程会拿到锁
     其实需要自己不断去尝试获取锁，比较消耗性能。

1.RedLock 算法虽然是需要多个实例，但是这些实例都是独自部署的，没有主从关系。
RedLock 作者指出，之所以要用独立的，是避免了 Redis 异步复制造成的锁丢失，
比如：主节点没来的及把刚刚 Set 进来这条数据给从节点，就挂了。如上面第二点说的
问题

2.红锁算法认为，只要 2N+1 个节点加锁成功，那么就认为获取了锁。
3.集群有5台节点三个节点加锁成功并且花费时间小于锁的有效期
4.认定加锁成功了

缺点：有一台机器重启,有两个线程拿到锁（概率很低）

加锁流程

首先在zookeeper创建根节点，也就是持久节点（rootNode）,作为锁节点
在根节点（rootNode）下创建临时节点（node_x）:
查询根节点的子节点列表，检查如果当前创建的节点的序号是最小话，就认定该客户端已经获得锁
如果不是最小的节点，说明获取锁失败，此时客户端就要找比自己小1的节点（node_x-1），
对其注册事件监听器（等待node_x-1的节点被删除的时候，通知当前节点获取锁）
获取锁的客户端在执行完业务就删除当前最小节点。删除最小节点后客户端会通过监听器收到通知，
然后再次判断是否自己的节点最小，是的话进行加锁，不是的话重复上述操作

释放锁流程

等待获取锁的客户端执行完业务流程，直接删除当前的最小的临时顺序节点（L）即可
这样监听L的删除事件的客户端，就会被通知到，尝试进行锁的获取

优点:zookeeper天生设计定位就是分布式协调，强一致性。锁的模型健壮、简单易用、适合做分布式锁。
如果获取不到锁，只需要添加一个监听器就可以了，不用一直轮询，性能消耗较小。

缺点:代码通过Watcher机制实现,实现相对复杂