-
-
- 如何实现分布式锁
-
- redis(自旋锁版本)
- [etcd 的分布式锁(互斥锁(信号控制)版本)](#etcd 的分布式锁(互斥锁(信号控制)版本))
- 分布式锁对比
-
-
- [redis vs etcd](#redis vs etcd)
-
- 总结
-
为什么要实现分布式锁?
- 了解分布式锁的底层工作原理,以及如果在工程中应用,我们应该如何选择.
为什么需要分布式锁,分布式锁的作用是什么,哪些场景会使用到分布式锁?
为什么需要分布式锁
- 解决分布式业务需要互斥的问题(同时只能有一次客户端的一个线程可以执行的场景),保护共享数据
- 具体场景: 支付业务(避免多端同时支付),消息队列的消费(避免多端同时消费产生重复消费的问题),服务器的偏执业务(有些业务(数据同步)只需要一个服务器执行,不需要全部都开启,这时候可以使用分布式锁,拿到锁的执行,其他就不执行)
分布式锁的作用
- 分布式实现线程互斥,确保只有一个线程能够执行
分布式锁的使用场景
- 需要分布式线程互斥逻辑的场景都可以使用分布式锁
分布式锁的实现方式有哪些
- redis 分布式锁
- etcd 分布式锁
- ...
分布式锁的核心原理是什么
- 互斥性:确保只有一个程序的一个线程可以获取到锁
- 死锁预防: 如果程序意外终止会释放锁而不是持续占用锁资源,导致死锁
- 实例自动回收(过期),客户端定时续期来实现
- 锁的公平竞争: 避免锁被饿死
如何实现分布式锁
redis(自旋锁版本)
-
原子性保证
- redis 单线程本身的读写都是原子的,没有并发问题
- 对相同的 key 使用 setnx(set not exit 只会在不存在的时候设置成功,如果存在表示锁被占用的情况则会返回 0(获取锁失败))
-
死锁预防:
-
使用 redis 过期机制实现
-
加锁: 使用合成命令或者 lua 脚本保证加锁的原子性
- 合成命令: setnx k v ex ex_time 一次性在获取锁的时候就设置完成过期时间
- 将获取锁与设置锁关过期时间的两条 redis 命令写到一个 lua 脚本中保证锁设置的原子性
- 可不可以将其拆分成为两步:先抢锁(setnx),在设置过期时间(setex)
- 不可以:因为设置过期时间可能有失败的风险(比如网络问题导致失败,那么这个可以有死锁的风险
- 可不可以将其拆分成为两步:先抢锁(setnx),在设置过期时间(setex)
- 续期:
- 如果加锁成功则立即开启定时任务(ticker),定时更新过期时间,直到锁的释放(接收到 delete 信号)
- 避免信号延迟或者丢失造成锁的自动过期导致的原子性被破坏(多个线程同时获取到锁):一个过期时间内将会发送三次续期的心跳,只要任何一个续期请求到达 redis 都可以续期成功
- 锁的公平性:
- 所有的锁都以自旋的方式获取锁,公平的竞争锁
- 自旋时间间隔随自旋的次数增加而减少(每次自旋减少 1ms,最低 10ms 自旋一次),所以阻塞时间越久的线程获取到锁的概率越高,防止锁被饿死.
- 问题,再大量并发的情况下,依旧有被饿死的风险
- 所有的锁都以自旋的方式获取锁,公平的竞争锁
- 锁的误删避免: 确保每个线程只能删除自己的锁不能删除其他线程的锁
- 如果锁的删除命令因为网络等原因导致延迟到达(其他线程获取了锁,这时删除命令到达,会误删去他的锁,破坏锁的原子性)
- 使用唯一 value + lua 脚本进行实现
- 使用 lua 脚本在保证原子性的情况下删除自己的 key
- 加锁时 value 在客户端生成唯一标识(可以使用 uuid)
- 释放锁的时候:lua(检查 redis 中value 是否与客户端的 value 相同,如果相同就删除,如果不同证明自己已经不持有该锁,就不做任何操作)
- 使用 lua 脚本在保证原子性的情况下删除自己的 key
-
etcd 的分布式锁(互斥锁(信号控制)版本)
etcd 没有像 redis 那样 setnx 的命令,但是他的 Revision(版本号)与 watch 机制可以实现锁
- 原子性: 保证只有一个线程获取到锁
- 预写: 所有获取锁的线程都会先将 k-v 写到 etcd 中,etcd 会给每个写操作都迭代一个递增的版本号(获取锁的基本原理就是所有 kv 中最小的为当前持有锁)(有问题)
- 试加锁: 再检查自己的版本号是否是列表中最小的(如果是就获取到锁,直接返回)
- 等待锁 :等待自己前面的锁全部释放,直到自己是 kv 对中版本最小的一个
- 使用 watch 监听自己前面的删除,直到自己前面已经没有任何 kv 对(有点问题在里面)
- 再检查: 检查自己的kv 对是否在队列中,如果不在就不能加锁,因为不知道被谁删除了,或者过期了,就自己返回错误)(因为你的 k-v 不在 etcd 中的话,你的后面一个就会发现自己是最小的,如果你也运行程序,那么就会有两个线程同时获取到锁,破坏锁的原子性,所以要先检查再获取锁)
- 防止死锁:
- 租约 : etcd 有自己的租约,每一个 k-v 设置的时候就会绑定租约(与 redis 的过期时间+心跳续期的原理类似,只是这个是隐式的,在会话中实现的)
- 当锁释放的时候就会停止续租并删除 k-v对(在后面的线程就会监听到他的删除)
- 锁的公平性:(版本号 )
- etcd 锁是天然公平的,是通过每个 kv 的版本号控制的
- 因为版本号是递增的,那么整个锁就形成了一个先进先出的队列模式,只有到达队头(版本号最小)的线程会获取到锁执行业务逻辑,其他线程都是阻塞等待的状态
- 锁的误删:
- etcd 中每个锁都只持有自己的 key,所以只能对自己的 k-v 对进行操作,不会出现误删的情况.
分布式锁对比
redis vs etcd
性能: 吞吐量
redis: 性能本身就更好,redis 有 20w 并发
redis 的性能瓶颈在网络 io,Reds 使用的 tcp 的协议,io 的性能就是 20 万
etcd 要略低只有 10 多万作用
etcd 使用的 grpc 的架构,底层是 http2 的传输协议; grpc 的性能是 15 万的 qps,所以 etcd 的性能只有 15 万左右
强一致性
Redis 分片的意外崩溃可能会导致锁的原子性被破坏
解决方法:redlock 模式
etcd 集群本身具有强一致性,不需要担心单个实例的崩溃破坏锁原子性的问题
服务器的影响:
redis 使用的自旋的形式获取锁,会消费一定的服务器 cpu
etcd 是等待信号通知的形式(watch),不需要自旋与循环,对服务器性能影响小
实例储存的数据量
Redis 一个 lock 只需要维护一个 k-v 对,储存数据少,但是 Redis 可能会处理大量自旋请求.
etcd 每一个线程的获取锁都是一个 k- v 对,储存的数据多,并且要维护所有线程的连接,开销大,不能同时接受太多获取锁的请求,否则会资源耗尽(连接)(如果并发数量高,并且有线程长期持有锁可能会导致连接的大量堆积)
总结
- 当我们不需要很强的一致性,但是需要比较高的性能的时候,大量并发获取锁的情景下我们可以选择 Redis 的分布式锁
- 如果我们需要强一致,高性能,高并发的场景的话我们可以使用 Redis 的 redlock 模式
- 如果我们需要强一致,但是性能不需要太高,并且并发数量并不高的情况,可以选择使用 etcd 的分布式锁
参考:
https://blog.csdn.net/qq_16399991/article/details/130732780