作者: 西魏陶渊明 博客: https://blog.springlearn.cn/ (opens new window)
西魏陶渊明
在单机环境下多线程操作共享数据时候回用到锁的概念,因为是单机可以直接使用jdk提供的锁机制就可以满足。 但是在微服务场景下,因为是多服务共享数据,此时jdk提供的锁就不能再使用了。于是乎就有了分布式锁。 本文介绍常见的几种可以使用的生产的分布式锁
本文面向有开发经验的同学,所以场景就不赘述,直接上干货
# 一、分布式锁具有的品格
- 基本的加锁和释放锁
- 具备锁失效机制,防止死锁
- 非阻塞机制
- 高性能和高可用
# 二、思考一下如何自己实现?
# 1. db
根据上面提出的要求,发现只要能满足多服务之前通信就能实现。 比如我们可以用mysql就能实现,比如A服务对一个表加锁和释放锁。B服务就会发现表加了锁。此时B就阻塞了。
当然这明显不满足,非阻塞的机制。另外如果要用一个数据库来做锁的场景也太浪费性能了。
# 2. redis
利用redis命令来实现,如果返回ok说明获取锁。返回nil说明没有获取到锁。
不阻塞,防止死锁,高性能,都满足
1 2 3 4 5 6 7 8 9 10
# 3. zookeeper
# 获取锁
- 在Zookeeper当中创建一个持久节点ParentLock。当第一个客户端想要获得锁时,需要在ParentLock这个节点下面创建一个临时顺序节点 Lock1。
- Client1查找ParentLock下面所有的临时顺序节点并排序,判断自己所创建的节点Lock1是不是顺序最靠前的一个。如果是第一个节点,则成功获得锁。
- 如果再有一个客户端 Client2 前来获取锁,则在ParentLock下载再创建一个临时顺序节点Lock2。 此时Client2发现自己并不是最靠前的就像Lock1注册了一个Watcher,用于监听Lock1节点释放。此时Client2就进入等待状态
- Client3,4以此类推
# 释放锁
- Client1释放了锁,此时Zookeeper就讲Lock1移出,并触发了Lock1的Watcher。
- Client2一直在监听Lock1的状态,当Lock1节点被删除,Client2里面收到通知获得了锁。
# 三、现成的解决方案
# 1. db的方式就不考虑了
实现简单,但是不划算,性能也不是最好的。
# 2. redis
1 2 3 4 5
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45
通过官方文档能找到实现第三方工具
# 3. zookeeper
Curator (opens new window)
1 2 3 4 5 6 7 8 9 10 11 12
几乎对所有的JDK锁都实现了,基于Zookeeper的分布式锁。具体使用方法可以自行百度。
- InterProcessMutex:分布式可重入排它锁
- InterProcessSemaphoreMutex:分布式排它锁
- InterProcessReadWriteLock:分布式读写锁
- InterProcessMultiLock:将多个锁作为单个实体管理的容器
- InterProcessSemaphoreV2 信号量
- DistributedBarrier 分布式栅栏
- DistributedDoubleBarrier 分布式栅栏
最后求关注,求订阅,谢谢你的阅读!