浅谈分布式锁

女主宣言

分布式锁是一个在分布式环境中重要的原语,它表明不同进程间采用互斥的方式操作共享资源。本文将谈谈分布式相关的内容。

 

1

分布式锁概述 

从进程锁到分布式锁

 

在单进程环境中,为了防止多线程同时对共享资源进行读写操作,我们通常使用内核或者类库实现线程间的互斥。当扩展到分布式系统下,我们需要提供相同功能的分布式锁服务,不同的主机通过该服务获取一把锁,而获取该锁的机器就可以排他性的访问共享资源。

浅谈分布式锁

在单机环境下,操作系统知道自己进程的状态,当进程挂掉的时候该进程会释放自己持有的锁资源,但在分布式环境下,存在宕机、网络分区、时延等各种异常状态,因此需要给分布式锁提供新的特性:可用性。

分布式锁的系统分类

 

 

基于锁资源的安全性,可以将分布式锁分为以下两部分:

  1. 基于异步复制的分布式系统,例如:redis、mysql

  2. 基于paxos协议的分布式一致性系统,例如:etcd、zookeeper

基于异步复制的分布式系统,存在丢锁的风险,不够安全,通常使用TTL机制承担细粒度的锁服务,该系统接入简单,适用于对事件很敏感,期望设置一个较短的有效时间,执行短期任务,丢锁对业务影响相对可控的服务。

基于paxos协议的分布式系统,通过一致性协议保证数据的多副本,数据的安全性高,通常使用lease机制承担粗粒度的锁服务,适用于对安全性很敏感,希望长期持有锁,不希望发生丢锁现象的服务。

2

基于 redis 的分布式锁

通常可以使用setnx(set if not exists)实现排他的获取锁操作,但是由于分布式系统中进程可能随时宕机,因此获取锁时,需要添加TTL保证锁不会因为进程挂掉之后变成死锁状态,但是此时又出现了第二个问题,那就是setnx和expire操作必须是原子操作,因为setnx之后,如果进程挂掉,expire有可能没有机会执行,这同样会导致死锁。正确的操作如下:

  •  
SET lock_name value NX EX lock_time
  1. EX second:设置 key 的过期时间,单位是秒

  2. NX:当 key 不存在的时候进行设置,等同于 SETNX 操作

释放锁时,只需要调用DEL命令删除锁即可:

  •  
DEL lock_name

需要注意的是,这里有可能出现错误删除锁的问题。场景如下:

  1. 进程A加锁成功,锁超时时间20秒。由于进程A业务逻辑执行过长,20秒之后,锁过期自动释放。

  2. 此时进程B接着加锁,加锁成功后,执行业务逻辑。这期间,进程A结束执行,使用DEL释放锁。

这样就导致进程A错误的释放进程B的锁。因此,为了不被错误的释放锁,我们在加锁的时候需要设置UUID。例如:

  •  
SET lock_name uuid NX EX lock_time

释放锁时,需要先获取锁的UUID,如果是自己分配的,则释放锁。但是这里的比较和释放操作必须是原子操作,否则会出现获获取锁比对的时候正确,此时正好TTL过期,另一个进程加锁成功,这样的话还是会出现错误释放锁的操作。可以使用Lua脚本实现判断与删除的原子操作。

3

基于 etcd/zookeeper 的分布式锁

排他锁(exclusive locks)

 

排他锁(写锁、独占锁)表现如下:

进程p1对数据d1加上排他锁,那么在整个加锁期间,只允许进程p1对数据d1进行读取和更新操作,其他任何进程都不能再对整个数据进行任何类型的操作。直到p1释放排他锁。

通过在zk/etcd上的数据节点来表示一个锁

浅谈分布式锁

上面/exclusive_lock/lock1节点,就可以被定义为一个锁。

获取锁:

  1. 创建排他锁:需要获取排他锁的时候,所有的客户端都会试图调用create()接口,在/exclusive_lock节点下创建临时子节点/exclusive_lock/lock1。zk/etcd会保证在所有的客户端中,最终只有一个客户端能够创建成功,那么就可以为该客户端获取锁。

  2. watch排他锁:所有没有成功获取锁的客户端就要到/exclusive_lock节点上注册一个子节点变更的watcher监听,用于实时监听lock1节点的变更情况。

释放锁即移除该临时节点。由于/exclusive_lock/lock1是一个临时节点(etcd通过租约,通过发送心跳来续租),因此需要考虑以下情况:

  1. 已经获取锁的client发生了宕机,那么zk/etcd上整个临时节点就会被移除

  2. 正常完成业务之后,client会主动删除临时节点

无论在什么情况下移除lock节点,zk/etcd都会通知所有watcher /exclusive_lock的客户端。这些客户端在接受到通知之后,再次重新发起分布式锁获取,即重复获取锁过程。

浅谈分布式锁

共享锁(shared locks)

 

共享锁(读锁)表现如下:

进程p1对数据d1加上共享锁,那么当前事务只能对d1进行读取操作,其他事务也只能对整个数据加共享锁,直到该数据对象上的所有共享锁都被释放。

与排他锁的区别是,加上排他锁之后,数据只对一个事务可见,而加上共享锁之后,数据对所有事务可见。

定义锁:

同样是通过zk/etcd上的数据节点表示一个锁,格式可以参考/shared_lock/[hostname]-请求类型-序号 的临时节点。

例如:下图中/shared_lock/host1-R-001就代表了一个共享锁

浅谈分布式锁

需要获取共享锁时,所有客户端都会到/shared_lock整个节点下创建一个临时顺序节点。

  1. 如果当前是读请求,创建/shared_lock/192.168.0.1-R-01节点

  2. 如果是写请求,创建/shared_lock/192.168.0.1-W-02节点

根据共享锁的定义,

  1. 不同的事务可以对同一数据对象进行读取操作

  2. 更新操作必须在当前没有任何事务进行读写操作的情况下进行

zk/etcd的读写顺序:

  1. 创建完节点,获取/shared_lock节点下的所有子节点,并对该节点注册子节点变更的watcher监听

  2. 确定自己的节点序号,在所有子节点中的顺序

  3. 对于读请求:

    1. 如果没有比自己小的子节点,或者所有比自己小的子节点都是读请求,那么自己已经成功获取到共享锁,可以开始业务逻辑

    2. 如果比自己小的节点中有写请求,那么需要进入等待

  4. 对于写请求:

    1. 如果自己不是序号最小的子节点,那么就需要进入等待

  5. 接收到watcher通知后,重复步骤1

释放锁与排他锁是一致的:

 

浅谈分布式锁

例子:

浅谈分布式锁

  1. 主机10.16.0.1先进行读操作,完成后,将节点/shared_lock/10.16.0.1-R-000001删除

  2. 剩余4台机器均收到节点移除通知,然后重新从/shared_lock节点上获取一份新的子节点列表

  3. 每个主机判读自己的读写顺序。接着,主机10.16.0.2检测到自己已经是需要最小的了,于是开始执行写操作,而其他主机发现没有轮到自己进行读取或者更新操作,于是继续等待

  4. 继续上面循环

 

浅谈分布式锁

 

上一篇:测开之路一百一十三:bootstrap媒体对象


下一篇:C++学习之字符串类、容器