Java面试题总结17之分布式锁解决方案

1、基于关系型数据库，如MySQL（利用主键冲突控制一次之后一个线程能获取锁，缺点:非阻塞，不可重入，单点，失效时间）

基于关系型数据库实现分布式锁，是依赖数据库的唯一性来实现资源锁定，比如主键和唯一索引等。

缺点：

• 这把锁强依赖数据库的可用性，数据库是一个单点，一旦数据库挂掉，会导致业务系统不可用。
• 这把锁没有失效时间，一旦解锁操作失败，就会导致锁记录一直在数据库中，其他线程无法再获得到锁。
• 这把锁只能是非阻塞的，因为数据的insert操作，一旦插入失败就会直接报错。没有获得锁的线程并不会进入排队队列，要想再次获得锁就要再次触发获得锁操作。
• 这把锁是非重入的，同一个线程在没有释放锁之前无法再次获得该锁。因为数据中数据已经存在了。

2、基于Redis实现（核心）setNX，单线程处理网络请求，不需要考虑并发安全性

所有服务节点设置相同的key，返回为零，则锁获取失败

早期版本没有超时参数，需要单独设置，存在死锁问题

后期版本提供加锁与设置时11子操作，但是存在任务超时，锁自动释放，导致并发问题，加锁与释放锁不是同一线程问题

删除锁：判断线程唯一标识，再删除

可重入性及锁续期没有实现，通过redisson解决类似AQS的实现，看门狗监听机制

redlock：都只操作单节点，即使Redis通过sentinel保证高可用，如果这个master节点由于某些原因发生了主从切换，那么就会出现锁丢失的情况（redis同步设置可能数据丢失），redlock从多个节点申请锁，当一半以上节点获取成功，锁才算获取成功，redission中也有相应的实现

优点：

Redis 锁实现简单，理解逻辑简单，性能好，可以支撑高并发的获取、释放锁操作。

缺点：

• Redis 容易单点故障，集群部署，并不是强一致性的，锁的不够健壮；
• key 的过期时间设置多少不明确，只能根据实际情况调整；
• 需要自己不断去尝试获取锁，比较消耗性能。

3、基于zookeeper(通过临时节点，解决死锁问题，一旦客户端获取到锁之后突然挂掉（session连接断开，那么这个临时节点就会自动删除掉，其他客户端自动获取锁，临时顺序节点解决惊群效应)

优点：

zookeeper 天生设计定位就是分布式协调，强一致性，锁很健壮。如果获取不到锁，只需要添加一个监听器就可以了，不用一直轮询，性能消耗较小。

缺点：

在高请求高并发下，系统疯狂的加锁释放锁，最后 zookeeper承受不住这么大的压力可能会存在宕机的风险。