聊一聊:常见的分布式锁

本文最后更新于:2021年11月7日 下午

前言

在分布式系统中,为了实现对互斥资源的安全访问(独占),必须要用到分布式锁。另外在工作中,还有一个应用场景是,在分布式的后台服务中,某些服务只允许单个实例(机器或 Docker)运行,其他的备份机器作为 BackUps 备份节点(比如在笔者的项目中,负责数据同步的逻辑同一时刻只能有一台机器进程来执行),当正在运行的单实例机器(进程)故障后,在线的 BackUps 按照排队顺序,争抢到分布式锁,继续执行,这样也保证了单实例场景的高可用性。

分布式锁应具备以下特点:

  • 互斥性:任意时刻,同一个锁,只有一个进程能持有
  • 安全性:避免死锁,当进程没有主动释放锁(进程崩溃退出),保证其他进程能够加锁
  • 可用性:当提供锁的服务节点故障(宕机)时,热备节点能够接替故障的节点继续提供服务,并保证自身持有的数据与故障节点一致
  • 对称性:对同一个锁,加锁和解锁必须是同一个进程,即某进程不能把其他进程持有的锁给释放了

可以 基于数据库 / 缓存 / 中间件等实现分布式锁,当下比较主流的是使用 Redis、Etcd 或 ZooKeeper 等开源项目来构建 。

分布式锁的实现方案

要实现分布式锁,核心在两点,一是如何达成共识、二是状态同步。目前的实现方式一般会借助于 Redis/ZooKeeper/Etcd 来实现:

  1. 采用 Redis 的 SETNX 命令 + Lua 原子脚本来实现(单 Redis 实例),存在单点的风险
  2. 1 的改进版是采用 Redis Master 集群的 Redlock 改进算法
  3. 基于 ZooKeeper 实现的分布式锁
  4. 基于 Etcd 实现的分布式锁:分布式锁的最佳实践之:基于 Etcd 的分布式锁

接下来我将主要展示一下,golang基于这些开源库的分布式锁的实现

Redis实现

手头的项目由于任务队列的中间件使用的也是redis,并使用了cluster模式不支持的指令(lrpop什么的),所以使用的是基于哨兵模式的redis集群。考虑到当前业务的实际需求,我们是使用最朴素的方法。redis的实现已经有了很多成熟的开源库,比如github.com/bsm/redislock,以下是实现:

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
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
package main

import (
"context"
"fmt"
"log"
"time"

"github.com/bsm/redislock"
"github.com/go-redis/redis/v8"
)

func main() {
// Connect to redis.
client := redis.NewClient(&redis.Options{
Network: "tcp",
Addr: "127.0.0.1:6379",
})
defer client.Close()

// Create a new lock client.
locker := redislock.New(client)

ctx := context.Background()

// Try to obtain lock.
lock, err := locker.Obtain(ctx, "my-key", 5*time.Second, nil)
if err == redislock.ErrNotObtained {
fmt.Println("Could not obtain lock!")
return
} else if err != nil {
log.Fatalln(err)
}

// Don't forget to defer Release.
defer lock.Release(ctx)
fmt.Println("I have a lock!")

// Sleep and check the remaining TTL.
time.Sleep(50 * time.Millisecond)
if ttl, err := lock.TTL(ctx); err != nil {
log.Fatalln(err)
} else if ttl > 0 {
fmt.Println("Yay, I still have my lock!")
}

// Extend my lock.
if err := lock.Refresh(ctx, 10*time.Second, nil); err != nil {
log.Fatalln(err)
}

// Sleep a little longer, then check.
time.Sleep(11 * time.Second)
if ttl, err := lock.TTL(ctx); err != nil {
log.Fatalln(err)
} else if ttl == 0 {
fmt.Println("Now, my lock has expired!")
}

}

ETCD实现

这些年,随着 Raft 协议 的广泛应用,涌现出很多的基于此协议实现的高可用分布式系统,比较知名的有 EtcdConsul 等,由于其内部实现了 分布式一致性,所以非常适合做分布式锁。本片文章就以 Etcd 为例,来介绍下构建分布式锁的方法。值得注意的是,Etcd 分布式锁的实现是在客户端做的。

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
package main

import (
"context"
"flag"
"fmt"
"github.com/coreos/etcd/clientv3"
"github.com/coreos/etcd/clientv3/concurrency"
"log"
"time"
)

func main() {
var name = flag.String("name", "", "give a name")
flag.Parse()
// Create a etcd client
cli, err := clientv3.New(clientv3.Config{Endpoints: []string{"localhost:2379"}})
if err != nil {
log.Fatal(err)
}
defer cli.Close()
// create a sessions to aqcuire a lock
s, _ := concurrency.NewSession(cli)
defer s.Close()
l := concurrency.NewMutex(s, "/distributed-lock/")
ctx := context.Background()
// acquire lock (or wait to have it)
if err := l.Lock(ctx); err != nil {
log.Fatal(err)
}
fmt.Println("acquired lock for ", *name)
fmt.Println("Do some work in", *name)
time.Sleep(50 * time.Second)
if err := l.Unlock(ctx); err != nil {
log.Fatal(err)
}
fmt.Println("released lock for ", *name)
}

ZooKeeper实现

基于ZooKeeper的锁与基于Redis的锁的不同之处在于Lock成功之前会一直阻塞,这与我们单机场景中的mutex.Lock很相似。

其原理也是基于临时Sequence节点和watch API,例如我们这里使用的是/lock节点。Lock会在该节点下的节点列表中插入自己的值,只要节点下的子节点发生变化,就会通知所有watch该节点的程序。这时候程序会检查当前节点下最小的子节点的id是否与自己的一致。如果一致,说明加锁成功了。

这种分布式的阻塞锁比较适合分布式任务调度场景,但不适合高频次持锁时间短的抢锁场景。按照Google的Chubby论文里的阐述,基于强一致协议的锁适用于粗粒度的加锁操作。这里的粗粒度指锁占用时间较长。我们在使用时也应思考在自己的业务场景中使用是否合适。

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
package main

import (
"time"

"github.com/samuel/go-zookeeper/zk"
)

func main() {
c, _, err := zk.Connect([]string{"127.0.0.1"}, time.Second) //*10)
if err != nil {
panic(err)
}
l := zk.NewLock(c, "/lock", zk.WorldACL(zk.PermAll))
err = l.Lock()
if err != nil {
panic(err)
}
println("lock succ, do your business logic")

time.Sleep(time.Second * 10)

// do some thing
l.Unlock()
println("unlock succ, finish business logic")
}

如何选择合适的锁

业务还在单机就可以搞定的量级时,那么按照需求使用任意的单机锁方案就可以。

如果发展到了分布式服务阶段,但业务规模不大,qps很小的情况下,使用哪种锁方案都差不多。如果公司内已有可以使用的ZooKeeper、etcd或者Redis集群,那么就尽量在不引入新的技术栈的情况下满足业务需求。

业务发展到一定量级的话,就需要从多方面来考虑了。首先是你的锁是否在任何恶劣的条件下都不允许数据丢失,如果不允许,那么就不要使用Redis的setnx的简单锁。

对锁数据的可靠性要求极高的话,那只能使用etcd或者ZooKeeper这种通过一致性协议保证数据可靠性的锁方案。但可靠的背面往往都是较低的吞吐量和较高的延迟。需要根据业务的量级对其进行压力测试,以确保分布式锁所使用的etcd或ZooKeeper集群可以承受得住实际的业务请求压力。需要注意的是,etcd和Zookeeper集群是没有办法通过增加节点来提高其性能的。要对其进行横向扩展,只能增加搭建多个集群来支持更多的请求。这会进一步提高对运维和监控的要求。多个集群可能需要引入proxy,没有proxy那就需要业务去根据某个业务id来做分片。如果业务已经上线的情况下做扩展,还要考虑数据的动态迁移。这些都不是容易的事情。

在选择具体的方案时,还是需要多加思考,对风险早做预估。


本博客所有文章除特别声明外,均采用 CC BY-SA 4.0 协议 ,转载请注明出处!