大家好，又见面了，我是你们的朋友全栈君。
工作中用到了分布式锁,特意研究了下各种场景和实现方案。
为什么用分布式锁?
其实提到锁这个东西,我理解它有点类似现实生活中的锁。
举个例子:比如门锁，现实生活中我们为什么用门锁,因为防止更多人进去。
那结合到我们编程中来道理也是一样的,在一些特定场景，一些特定的资源是有限的。（比如库存等）这个时候我们要加上锁，其实可以理解成钥匙,有锁钥匙的人才能走下面的流程
应用场景:
1.最常见扣减库存
2.缓存击穿/缓存雪崩（也可以采用分布式锁）
3.在高并发的场景下,阻止流量打到后边等等
实现方案:
1.利用mysql实现分布式锁
代码语言：javascript复制1.创建锁表，利用唯一性约束,获取锁时插入数据库。
2.释放锁时,删除数据
优点:容易理解,实现简单
缺点:性能比较差,适合并发不高的场景2.基于redis setnx实现分布式锁
代码语言：javascript复制1.主要设置锁的超时时间,避免死锁
2.如果锁过期了事情没干完-使用多线程（守护线程）延长过期
3.为了保证原子性操作,实现的时候采用Redisson(API实现比较简单/源码中加锁/释放锁操作都是用 Lua 脚本完成的，封装的非常完善，开箱即用)
优点:redis的性能很高，可以支撑高并发的获取、释放锁操作。
缺点:集群环境下,主节点宕机时,两个线程会拿到锁
其实需要自己不断去尝试获取锁，比较消耗性能。3.基于redLock实现分布式锁
代码语言：javascript复制1.RedLock 算法虽然是需要多个实例，但是这些实例都是独自部署的，没有主从关系。
RedLock 作者指出，之所以要用独立的，是避免了 Redis 异步复制造成的锁丢失，
比如：主节点没来的及把刚刚 Set 进来这条数据给从节点，就挂了。如上面第二点说的
问题
2.红锁算法认为，只要 2N 1 个节点加锁成功，那么就认为获取了锁。
3.集群有5台节点三个节点加锁成功并且花费时间小于锁的有效期
4.认定加锁成功了
缺点：有一台机器重启,有两个线程拿到锁（概率很低）4.基于zookeeper实现分布式锁
代码语言：javascript复制加锁流程
首先在zookeeper创建根节点，也就是持久节点（rootNode）,作为锁节点
在根节点（rootNode）下创建临时节点（node_x）:
查询根节点的子节点列表，检查如果当前创建的节点的序号是最小话，就认定该客户端已经获得锁
如果不是最小的节点，说明获取锁失败，此时客户端就要找比自己小1的节点（node_x-1），
对其注册事件监听器（等待node_x-1的节点被删除的时候，通知当前节点获取锁）
获取锁的客户端在执行完业务就删除当前最小节点。删除最小节点后客户端会通过监听器收到通知，
然后再次判断是否自己的节点最小，是的话进行加锁，不是的话重复上述操作
释放锁流程
等待获取锁的客户端执行完业务流程，直接删除当前的最小的临时顺序节点（L）即可
这样监听L的删除事件的客户端，就会被通知到，尝试进行锁的获取
优点:zookeeper天生设计定位就是分布式协调，强一致性。锁的模型健壮、简单易用、适合做分布式锁。
如果获取不到锁，只需要添加一个监听器就可以了，不用一直轮询，性能消耗较小。
缺点:代码通过Watcher机制实现,实现相对复杂上面介绍了目前主流做分布式锁的方案，咱们在做技术选项和对比的时候.根据实际应用场景选择合适的方案把。其实用的比较多直接单独用一台redis来做分布式锁，其实已满足大部分场景了。
其实每一种实现方案都是有它的优缺点的,我们在知道它的优缺点以后再进行选择。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
