笔记系列之分布式锁选择

为什么要用分布式锁

其实我们都知道，JDK自身是提供了锁的机制，比如synchronized或者ReentrantLock，但是原生锁在分布式环境，也就是集群部署环境下就失效了，问题就是锁无法在多个机器中共享，也就是没办法让多机器下的商品用一把锁控制住，这样的话就会出现超卖的情况

解决方案：保证两台或者多台机器的锁共享，是同一把锁--也就是分布式锁

Redis实现分布式锁

 Redis自身提供了setNx和redisson两个锁实现方式，唯一的区别就是redisson有一个看门狗机制，用来给上锁的逻辑进行续时，排除了逻辑还没走完，锁就到达过期时间自己释放了，具体的实现场景，见下方链接https://note.youdao.com/ynoteshare/index.html?id=095f8f46b8d7b0fa4a323c6ca0f363c3&type=note&_time=1647241786005https://note.youdao.com/ynoteshare/index.html?id=095f8f46b8d7b0fa4a323c6ca0f363c3&type=note&_time=1647241786005

ZooKeeper实现分布式锁

ZooKeeper的实现逻辑主要基于它自身的节点设计，同级节点不可重复，而且还提供了临时节点机制可以设置过期时间

---

两者对比 

• 性能方面，redis消耗比zk大，但redis的性能是十分可观的，如果请求比较多，zk压力会比较大
• 锁的健壮，因为Redis的设计就没有保证数据的强一致性，在一些特殊的场景下，可能会出现问题，而zk的设定就是强一致性的，而且使用起来，zk相对简单，zk相对来说更适合做分布式锁

---

 最后选择

其实都行

虽然redis有一定的问题，但是也是在非常极端的情况下才会出现，几率是十分十分小的，而且业界用的最多的是redis分布式锁，zk其实也没问题

zk在集群环境下，有个弊端：如果超过一半以上的节点挂掉了，那zk整个集群就会停止工作，这个就是zk没有保证可用性的弊端

具体选择哪一个就看场景，个人觉得其实都一样，我用的最多的就是redis分布式锁