什么是分布式锁
分布式锁(多服务共享锁)在分布式的部署环境下,通过锁机制来让多客户端互斥的对共享资源进行访问/操作。
为什么需要分布式锁
在单体应用服务里,不同的客户端操作同一个资源,我们可以通过操作系统提供的互斥(锁/信号量等等)来提供互斥的能力,保证操作资源的只有一个客户端。
在分布式的情况里,就需要第三方组件来保证对统一资源的操作的互斥。
(下单中,两个人下单,一个人下单请求走订单服务A机器,另一个人下单请求走订单服务B,这样用单体的思维处理就可能不是很合适,需要借用第三方组件配合来实现分布式锁)
分布式锁可以用redis, zookeeper , etcd等等来实现,下面我们简单说说....
redis分布式锁
简单例子
set key value ex/px nx 或setnx
以setnx 为例,可以使用 setnx key value 来进行 "加锁" ( setnx 主要 是nx加了语义:如果存在就不操作,不存在就添加),多个客户端确保只有一个加锁成功去操作统一资源
127.0.0.1:6379[1]> setnx lockObj 1 // 加锁
(integer) 1
127.0.0.1:6379[1]> setnx lockObj 1 // 存在了就不能再加锁
(integer) 0
127.0.0.1:6379[1]> get lockObj
"1"
127.0.0.1:6379[1]> del lockObj // 释放锁
(integer) 1
127.0.0.1:6379[1]> get lockObj
(nil)
127.0.0.1:6379[1]> setnx lockObj 1
(integer) 1
上面就是简单的加锁的例子,仔细思考下分布式锁使用的使用我们需要考虑哪些问题?
存在的问题
简单的总结了下,我们在使用redis分布式锁的时候需要考虑如下情况:
1- 死锁问题
2- 续锁生命周期
3- 操作原子性
4- 锁的归属权
5- redis 集群,锁的状态一致性
死锁问题
如果我们业务代码出现bug或服务器出现问题,没有及时释放锁,那么其他的客户端就永远获取不到这个加锁的资格。
这个时候我们就可以加上对应的处理逻辑:
golang 加上defer 加锁锁逻辑 , python try-Except-finally 用finally 释放锁。并且在加锁的时候加上过期时间(根据业务进行合适的加)
续锁生命周期
上面我们可以解决锁的释放问题,但是我们的业务处理时间不一定百分百能知道处理的时间,这个时候如果锁过期了但是资源操作没有做完,那么就会出现问题。
在java的 Redisson 有个watch 续命机制, golang 的话可以 借鉴 Rllock ,开启一个守护进程监听,定时续命(一定要提前续命,不要等到到时间再续)
操作原子性
在我们进行加锁 加过期时间的时候,这两个操作不能分两步操作。因为如果setnx加锁成功了,这时候失败了,那么这个锁就永远被占用了。
根据这个问题我们可以使用lua脚本或者使用第三方模块是可以同时进行这两个步骤的
`if redis.call('setnx', KEYS[1], ARGV[1]) == 1 then return redis.call('PEXPIRE',KEYS[1],ARGV[2]) else return 0 end`
锁的归属权问题
现在有几个场景:
1- 客户端1 拿到锁处理业务, 没处理完已经过期了;这时候客户端2 拿到锁在处理,结果客户端1 处理完就释放锁了
2- 一个业务不同画像的人处理的业务不同,这时候我们就需要根据不同画像人进行分配 "锁"
我们在实际开发的时候有时候需要了解业务场景, 有时候需要给锁加一个所属权的令牌。可以在setnx key时,key设定特殊化的数值
redis 集群,锁的状态一致性
在redis采用集群(主从),如果master加锁失败了,这时候服务宕机了,slave还同步这个 key ,那么这个时候就会有客户端加锁成功
redis作者对于这个问题提出了解答:REDLOCK
zookeeper 实现分布式锁
简单例子
[zk: localhost:2181(CONNECTED) 62] create /lock
Created /lock
[zk: localhost:2181(CONNECTED) 63] create -s -e /lock/req // 创建临时节点
Created /lock/req0000000000
[zk: localhost:2181(CONNECTED) 64] create -s -e /lock/req
Created /lock/req0000000001
[zk: localhost:2181(CONNECTED) 65] create -s -e /lock/req
Created /lock/req0000000002
[zk: localhost:2181(CONNECTED) 67] ls /lock // 节点下的临时节点
[req0000000000, req0000000001, req0000000002]
[zk: localhost:2181(CONNECTED) 68] delete /lock/req0000000000 // 释放第一锁
golang的例子
Go
package main
import (
"fmt"
"github.com/samuel/go-zookeeper/zk"
"sort"
"time"
)
func sortChildren(children []string) {
sort.Slice(children, func(i, j int) bool {
return children[i] < children[j]
})
}
func main() {
go func() {
conn, _, err := zk.Connect([]string{"xx.xx.xx.xx:2181"}, time.Second*5)
if err != nil {
fmt.Println("Connect:", err.Error())
return
}
defer conn.Close()
lockPath := "/locksObj"
lockName := "lock"
// 创建锁的根节点
_, err = conn.Create(lockPath, []byte{}, int32(0), zk.WorldACL(zk.PermAll))
if err != nil && err != zk.ErrNodeExists {
fmt.Println("Create:", err.Error())
return
}
// 获取锁
lockNodePath, err := conn.CreateProtectedEphemeralSequential(lockPath+"/"+lockName+"-", []byte{}, zk.WorldACL(zk.PermAll))
if err != nil {
fmt.Println("CreateProtectedEphemeralSequential:", err.Error())
return
}
// dowork
for {
children, _, err := conn.Children(lockPath)
if err != nil {
fmt.Println("Children:", err.Error())
return
}
// 对子节点按照序列号进行排序
sortChildren(children)
// 检查自己创建的节点是否是第一个节点
if lockNodePath == lockPath+"/"+children[0] {
// 获取到了锁
fmt.Println("Acquired lock")
break
}
// 监听前一个节点的删除事件
exists, _, watch, err := conn.ExistsW(lockPath + "/" + children[0])
if err != nil {
fmt.Println("ExistsW: ", err.Error())
break
}
if !exists {
// 前一个节点已删除,再次检查自己创建的节点是否是第一个节点
children, _, err = conn.Children(lockPath)
if err != nil {
fmt.Println("Children: ", err.Error())
break
}
sortChildren(children)
if lockNodePath == lockPath+"/"+children[0] {
// 获取到了锁
fmt.Println("Acquired lock")
break
}
}
// 等待前一个节点的删除事件
<-watch
}
// 执行需要保护的代码
fmt.Println("====start-1====")
time.Sleep(3 * time.Second)
fmt.Println(11111111)
// 释放锁,删除自己创建的节点
err = conn.Delete(lockNodePath, -1)
if err != nil {
fmt.Println("Delete: ", err.Error())
return
}
fmt.Println("Released lock")
}()
go func() {
conn, _, err := zk.Connect([]string{"xx.xx.xx.xx:2181"}, time.Second*5)
if err != nil {
fmt.Println("Connect:", err.Error())
return
}
defer conn.Close()
lockPath := "/locksObj"
lockName := "lock"
// 创建锁的根节点
_, err = conn.Create(lockPath, []byte{}, int32(0), zk.WorldACL(zk.PermAll))
if err != nil && err != zk.ErrNodeExists {
fmt.Println("Create:", err.Error())
return
}
// 获取锁
lockNodePath, err := conn.CreateProtectedEphemeralSequential(lockPath+"/"+lockName+"-", []byte{}, zk.WorldACL(zk.PermAll))
if err != nil {
fmt.Println("CreateProtectedEphemeralSequential:", err.Error())
return
}
for {
children, _, err := conn.Children(lockPath)
if err != nil {
fmt.Println("Children:", err.Error())
return
}
// 对子节点按照序列号进行排序
sortChildren(children)
// 检查自己创建的节点是否是第一个节点
if lockNodePath == lockPath+"/"+children[0] {
// 获取到了锁
fmt.Println("Acquired lock")
break
}
// 监听前一个节点的删除事件
exists, _, watch, err := conn.ExistsW(lockPath + "/" + children[0])
if err != nil {
fmt.Println("ExistsW: ", err.Error())
break
}
if !exists {
// 前一个节点已删除,再次检查自己创建的节点是否是第一个节点
children, _, err = conn.Children(lockPath)
if err != nil {
fmt.Println("Children: ", err.Error())
break
}
sortChildren(children)
if lockNodePath == lockPath+"/"+children[0] {
// 获取到了锁
fmt.Println("Acquired lock")
break
}
}
// 等待前一个节点的删除事件
<-watch
}
// 执行需要保护的代码
fmt.Println("====start-2====")
time.Sleep(5 * time.Second)
fmt.Println(22222222)
// 释放锁,删除自己创建的节点
err = conn.Delete(lockNodePath, -1)
if err != nil {
fmt.Println("Delete: ", err.Error())
return
}
fmt.Println("Released lock")
}()
time.Sleep(10 * time.Second)
}
zookeeper 怎么实现 分布式锁的
zookeeper 会建立一个长链接,监听锁对象节点的状态和事件
ETCD实现 分布式锁
简单实现
Go
package main
import (
"context"
"fmt"
clientv3 "go.etcd.io/etcd/client/v3"
"time"
)
func main() {
go func() {
config := clientv3.Config{
Endpoints: []string{"xx.xx.xx.xx:2379"},
DialTimeout: 5 * time.Second,
}
// 获取客户端连接
client, err := clientv3.New(config)
if err != nil {
fmt.Println(err)
return
}
// 上锁
// 用于申请租约
lease := clientv3.NewLease(client)
// 申请一个10s的租约
leaseGrantResp, err := lease.Grant(context.TODO(), 10) //10s
if err != nil {
fmt.Println(err)
return
}
// 拿到租约的id
leaseID := leaseGrantResp.ID
ctx, cancelFunc := context.WithCancel(context.TODO())
// 停止
defer cancelFunc()
// 确保函数退出后,租约会失效
defer lease.Revoke(context.TODO(), leaseID)
// 自动续租
keepRespChan, err := lease.KeepAlive(ctx, leaseID)
if err != nil {
fmt.Println(err)
return
}
// 处理续租应答的协程
go func() {
select {
case keepResp := <-keepRespChan:
if keepRespChan == nil {
fmt.Println("lease has expired")
break
} else {
// 每秒会续租一次
fmt.Println("收到自动续租应答", keepResp.ID)
}
}
}()
// if key 不存在,then设置它,else抢锁失败
kv := clientv3.NewKV(client)
// 创建事务
txn := kv.Txn(context.TODO())
// 如果key不存在
txn.If(clientv3.Compare(clientv3.CreateRevision("/lockObj/lock/job"), "=", 0)).
Then(clientv3.OpPut("/lockObj/lock/job", "", clientv3.WithLease(leaseID))).
Else(clientv3.OpGet("/lockObj/lock/job")) //如果key存在
// 提交事务
txnResp, err := txn.Commit()
if err != nil {
fmt.Println(err)
return
}
// 判断是否抢到了锁
if !txnResp.Succeeded {
fmt.Println("锁被占用了:", string(txnResp.Responses[0].GetResponseRange().Kvs[0].Value))
return
}
// 处理业务
fmt.Println("======work======")
time.Sleep(5 * time.Second)
fmt.Println("======END======")
}()
time.Sleep(20 * time.Second)
}
实现原理
etcd 支持以下功能,正是依赖这些功能来实现分布式锁的:
- Lease机制:即租约机制(TTL,Time To Live),etcd可以为存储的kv对设置租约,当租约到期,kv将失效删除;同时也支持续约,keepalive
- Revision机制:每个key带有一个Revision属性值,etcd每进行一次事务对应的全局Revision值都会+1,因此每个key对应的Revision属性值都是全局唯一的。通过比较Revision的大小就可以知道进行写操作的顺序
- 在实现分布式锁时,多个程序同时抢锁,根据Revision值大小依次获得锁,避免"惊群效应",实现公平锁
- Prefix机制:也称为目录机制,可以根据前缀获得该目录下所有的key及其对应的属性值
- watch机制:watch支持watch某个固定的key或者一个前缀目录,当watch的key发生变化,客户端将收到通知
执行流程
- 步骤 1: 准备
客户端连接 Etcd,以 /lock/mylock 为前缀创建全局唯一的 key,假设第一个客户端对应的 key="/lock/mylock/UUID1",第二个为 key="/lock/mylock/UUID2";客户端分别为自己的 key 创建租约 - Lease,租约的长度根据业务耗时确定,假设为 15s;
- 步骤 2: 创建定时任务作为租约的"心跳"
当一个客户端持有锁期间,其它客户端只能等待,为了避免等待期间租约失效,客户端需创建一个定时任务作为"心跳"进行续约。此外,如果持有锁期间客户端崩溃,心跳停止,key 将因租约到期而被删除,从而锁释放,避免死锁。
- 步骤 3: 客户端将自己全局唯一的 key 写入 Etcd
进行 put 操作,将步骤 1 中创建的 key 绑定租约写入 Etcd,根据 Etcd 的 Revision 机制,假设两个客户端 put 操作返回的 Revision 分别为 1、2,客户端需记录 Revision 用以接下来判断自己是否获得锁。
- 步骤 4: 客户端判断是否获得锁
客户端以前缀 /lock/mylock 读取 keyValue 列表(keyValue 中带有 key 对应的 Revision),判断自己 key 的 Revision 是否为当前列表中最小的,如果是则认为获得锁;否则监听列表中前一个 Revision 比自己小的 key 的删除事件,一旦监听到删除事件或者因租约失效而删除的事件,则自己获得锁。
- 步骤 5: 执行业务
获得锁后,操作共享资源,执行业务代码。
- 步骤 6: 释放锁
完成业务流程后,删除对应的key释放锁。
扩展
马丁·克莱普曼 对 分布式锁以及对redlock的看法
分布式锁的目的是确保在可能尝试执行同一工作的多个节点中,只有一个节点实际执行该操作(至少一次只有一个)。
主要有两个功能:
1- 效率:使用锁可以避免不必要地重复相同的工作,多执行一次也无妨,只要最终正确就行
2- 正确性:锁定可以防止并发进程互相干扰并扰乱系统状态。如果锁定失败并且两个节点同时处理同一数据,则会导致文件损坏、数据丢失、永久不一致。
马丁认为锁在分布式系统使用会碰到以下三类问题:
1- 网络延迟:您可以保证数据包始终在某个保证的最大延迟内到达
2- GC问题: 导致锁无法续期等等问题
3- 时钟飘移:依赖于时钟的就容易出现问题
马丁认为redlock 强依赖于时钟,节点之间时钟不对,会使锁不可靠:
假设系统有五个 Redis 节点(A、B、C、D 和 E)和两个客户端(1 和 2)。如果其中一个 Redis 节点上的时钟向前跳动,会发生什么情况?
- 客户端 1 获取节点 A、B、C 上的锁。由于网络问题,无法访问 D 和 E。
- 节点C上的时钟向前跳跃,导致锁过期。
- 客户端2获取节点C、D、E上的锁。由于网络问题,无法访问A和B。
- 客户 1 和 2 现在都相信他们持有锁。
如果 C 在将锁持久保存到磁盘之前崩溃并立即重新启动,则可能会发生类似的问题。因此,Redlock 文档建议延迟重新启动崩溃的节点,至少要延迟最长寿命锁的生存时间。但这种重新启动延迟再次依赖于对时间的相当准确的测量,并且如果时钟跳跃就会失败。
马丁提出了 fencing token 方案
客户端 1 获取租约并获得令牌 33,但随后它进入长时间暂停状态并且租约到期。客户端 2 获取租约,获取令牌 34(数字始终增加),然后将其写入发送到存储服务,包括 34 的令牌。稍后,客户端 1 恢复正常并将其写入发送到存储服务,包括其令牌值 33。但是,存储服务器记得它已经处理了具有更高令牌编号 (34) 的写入,因此它拒绝具有令牌 33 的请求。
总结
分布式锁不是百分百安全,我们要根据实际使用情况来考虑锁的使用(解决效率问题还是正确行问题),在使用分布式锁的时候我们需要考虑锁的续期,锁归属,集群数据一致性,操作原子性,GC,时钟飘逸,网络延迟等等的问题。在cap 理论里, redis保证了ap, zk和etcd保证cp ,所以实际使用中根据业务的情况,选择redis/zk/etcd之一来实现分布式锁。