从redis setnx 来看看分布式锁
什么是分布式锁
分布式锁（多服务共享锁）在分布式的部署环境下，通过锁机制来让多客户端互斥的对共享资源进行访问/操作。
为什么需要分布式锁
在单体应用服务里，不同的客户端操作同一个资源，我们可以通过操作系统提供的互斥（锁/信号量等等）来提供互斥的能力，保证操作资源的只有一个客户端。
在分布式的情况里，就需要第三方组件来保证对统一资源的操作的互斥。
（下单中，两个人下单，一个人下单请求走订单服务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的例子
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实现 分布式锁
简单实现
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之一来实现分布式锁。