别再错误的使用分布式锁了

分布式锁

1. Zookeeper 实现分布式锁

zookeeper 主要解决分布式数据的一致性问题

1.1 zookeeper 节点类型

• 临时节点
  • 程序执行完或者程序出现异常或者会话结束了，临时节点就会消失
• 临时有序节点
  • 临时节点有序的排列
• 持久节点
  • 不论是程序执行完或者程序出现异常或者会话结束了，节点都不会消失
• 持久有序节点
  • 持久且有序的节点

1.2 zookeeper 的事务监听 watch

主要监听：

• 节点创建
• 节点删除
• 节点数据修改
• 子节点变更

1.3 错误的分布式锁

多个客户端去争夺创建一个临时节点（临时节点是唯一的）

当客户端很多的时候，同时去竞争一把锁，对zookeeper还是对系统都是一个压力。

惊群现象或者叫羊群效益，所以是错误的

1.4 正确的分布式锁

用临时有序节点实现

使用临时有序节点对请求进行一个排队，并且每个节点都只会监听在自己前面的那一个节点，只有当前面的节点释放，他才回去获取锁。

解决了惊群现象，达到的效果就是，同一时间只有一个客户端在竞争这个锁

1.5 zookeeper锁的种类

• 分布式可重入共享锁
• 分布式排它锁
• 分布式读写锁
• 用多个锁进行一组操作
• 共享信号量

2. Redis 分布式锁

2.1 分布式锁几大特性

• 互斥性。在任意时刻，只有一个客户端能持有锁，也叫唯一性。

• 不会发生死锁。即使有一个客户端在持有锁的期间崩溃而没有主动解锁，也能保证后续其他客户端能加锁。

• 解铃还须系铃人。加锁和解锁必须是同一个客户端，客户端自己不能把别人加的锁给解了，即不能误解锁。

• 锁不能自己失效。正常执行程序过程中，锁不能因为某些原因失效。

• 具有容错性。只要大多数Redis节点正常运行，客户端就能够获取和释放锁。

2.2 正确的分布式锁实现

2.2.1 redis分布式锁加锁流程

2.2.2 锁不能自己失效 的实现原理

可能会造成长时间占用锁

所以使用的前提：没有设置持有锁的时间

定时的判断这个锁的实效实现，如果判断这个锁快要失效了，就去延长这个锁的失效时间，从而实现哪怕我执行的时间久一点，也不会因为设置的过期时间到了而被删除

2.2.3 redis分布式锁解锁流程