三种常见分布式锁实现方案

1. 基于数据库实现

1.1 数据库分布式锁的优势

• 实现简单

1.2 数据库分布式锁的缺点

• 需要考虑数据库的可用性和性能，考虑多机部署、数据同步、主备切换等，会比较复杂
• 不具备可重入的特性
• 没有锁失效机制
• 不具备阻塞锁特性

1.3 实现原理

1. 在数据库中创建一个表，表中包含方法名等字段，并在方法名字段上创建唯一索引
2. 想要执行某个方法，就使用这个方法名向表中插入数据
3. 成功插入则获取锁，执行完成后删除对应的行数据释放锁。

 

1. 基于redis实现

1.1 redis分布式锁的优势

• redis高性能
• 命令支持好，使用方便

1.2 redis命令

• setnx：当且仅当key不存在时，set一个key为val的字符串，返回1；若key存在，则什么都不做，返回0。
• expire：为key设置一个超时时间，单位为second，超过这个时间锁会自动释放，避免死锁。
• delete：删除key

1.3 具体实现

• 获取锁的时候使用setnx加锁，并使用expire命令为锁添加一个超时时间，超过该时间则自动释放锁，锁的value值为一个随机生成的UUID。
• 获取锁的时候还设置一个获取的超时时间，若超过这个时间则放弃获取锁。
• 释放锁的时候，通过UUID判断是不是该锁，若是该锁，则执行delete进行锁释放。

2. 基于zookeeper实现

2.1 zookeeper分布式锁的优势

• 高可用
• 可重入
• 阻塞锁特性
• 可解决失效死锁问题

2.2 zookeeper分布式锁的缺点

• 需要频繁的创建和删除节点，性能上不如Redis方式

2.3 具体实现

ZooKeeper内部是一个分层的文件系统目录树结构，规定同一个目录下只能有一个唯一文件名。

• 创建一个目录mylock
• 线程A想获取锁就在mylock目录下创建临时顺序节点
• 获取mylock目录下所有的子节点，然后获取比自己小的兄弟节点，如果不存在，则说明当前线程顺序号最小，获得锁
• 线程B获取所有节点，判断自己不是最小节点，设置监听比自己次小的节点
• 线程A处理完，删除自己的节点，线程B监听到变更事件，判断自己是不是最小的节点，如果是则获得锁

 

参考

https://blog.csdn.net/xlgen157387/article/details/79036337