etcd实现分布式锁分析

3篇关于分布式锁的文章，可以结合看：
consul实现分布式锁：https://www.cnblogs.com/jiujuan/p/10527786.html
redis实现分布式锁：https://www.cnblogs.com/jiujuan/p/10595838.html
etcd实现分布式锁：https://www.cnblogs.com/jiujuan/p/12147809.html

分布式锁简介

---

在单机情况下，锁的环境比较简单，因为都是在单机的环境里。

而在分布式情况下，多机环境里。由原来的单机系统变成了分布式系统。分布式系统的多线程、多进程分布在不同的机器上，在加上网络这个因素，要控制一个共享资源的使用就复杂得多。比如，网络超时怎么办？网络不可用怎么办？发生死锁怎么办？ 等等... ... 一系列问题。

在分布式情况下，需要设计一种分布式锁，来解决这些问题。

分布式锁问题和特性

---

设想一下，如果是你来设计一个分布式锁，你会怎样考虑？锁应该具有哪些特性？获取锁过程中会出现什么问题？要解决哪些问题？

经过长时间google后，一般会出现下面这些主要问题：

死锁：什么是死锁？就是资源抢占的各方，彼此都在等待对方释放资源，以便自己能获取系统资源，但是没有哪一方退出，这时候就死锁了

惊群效应：多线程/多进程等待同一个socket事件，当这个事件发生时，这些线程/进程被同时唤醒，就是惊群

脑裂：当集群中出现 脑裂 的时候，往往会出现多个 master 的情况，这样数据的一致性会无法得到保障，从而导致整个服务无法正常运行

下面这些特性的：

高可用：也就是可靠性。组成集群的分布式锁系统，某一台机器锁不能提供服务了，其他机器仍然可以提供锁服务。

互斥性：就像单机系统的锁特性一样具有互斥性。不过分布式系统是由多个机器节点组成的。如果有一个节点获取了锁，其他节点必须等待锁释放或者锁超时后，才可以去获取锁资源。

可重入：一个节点获取了锁之后，还可以再次获取整个锁资源。

高效和锁超时：高效是指获取和释放锁高效。 锁超时，防止死锁的发生。

公平锁：节点依次获取锁资源。

etcd如何实现分布式锁

---

etcd是怎么解决上面这些问题？它提供了哪些功能来解决上述的特性。

• 1.raft

raft，是工程上使用较为广泛，强一致性、去中心化、高可用的分布式协议。

raft提供了分布式系统的可靠性功能。

读者可以自行查阅raft相关的资料。比如这个 raft网站，它不仅介绍了raft算法，还在网站最下面提供了不同语言的raft实现。raft算法比paxos算法好理解一些。

• 2.lease功能

lease功能，就是租约机制(time to live)。

1、etcd可以对存储key-value的数据设置租约，也就是给key-value设置一个过期时间，当租约到期，key-value将会失效而被etcd删除。

2、etcd同时也支持续约租期，可以通过客户端在租约到期之间续约，以避免key-value失效；

3、etcd还支持解约，一旦解约，与该租约绑定的key-value将会失效而删除。

Lease 功能可以保证分布式锁的安全性，为锁对应的 key 配置租约，即使锁的持有者因故障而不能主动释放锁，锁也会因租约到期而自动释放。

• 3.watch功能

监听功能。watch 机制支持监听某个固定的key，它也支持watch一个范围（前缀机制），当被watch的key或范围发生变化时，客户端将收到通知。

在实现分布式锁时，如果抢锁失败，可通过 Prefix 机制返回的 KeyValue 列表获得 Revision 比自己小且相差最小的 key（称为 pre-key），对 pre-key 进行监听，因为只有它释放锁，自己才能获得锁，如果 Watch 到 pre-key 的 DELETE 事件，则说明pre-ke已经释放，自己已经持有锁。

• 4.prefix功能

前缀机制。也称目录机制，如两个 key 命名如下：key1=“/mykey/key1″ , key2=”/mykey/key2″，那么，可以通过前缀-“/mykey”查询，返回包含两个 key-value 对的列表。可以和前面的watch功能配合使用。

例如，一个名为 /mylock 的锁，两个争抢它的客户端进行写操作，实际写入的 key 分别为：key1=”/mylock/UUID1″，key2=”/mylock/UUID2″，其中，UUID 表示全局唯一的 ID，确保两个 key 的唯一性。很显然，写操作都会成功，但返回的 Revision 不一样，那么，如何判断谁获得了锁呢？通过前缀 /mylock 查询，返回包含两个 key-value 对的的 KeyValue 列表，同时也包含它们的 Revision，通过 Revision 大小，客户端可以判断自己是否获得锁，如果抢锁失败，则等待锁释放（对应的 key 被删除或者租约过期），然后再判断自己是否可以获得锁。

lease 功能和 prefix功能，能解决上面的死锁问题。

• 5.revision功能

每个 key 带有一个 Revision 号，每进行一次事务加一，因此它是全局唯一的，如初始值为 0，进行一次 put(key, value)，key 的 Revision 变为 1；同样的操作，再进行一次，Revision 变为 2；换成 key1 进行 put(key1, value) 操作，Revision 将变为 3。

这种机制有一个作用：

通过 Revision 的大小就可以知道进行写操作的顺序。在实现分布式锁时，多个客户端同时抢锁，根据 Revision 号大小依次获得锁，可以避免 “羊群效应” （也称 “惊群效应”），实现公平锁。

etcd的V3版本分布式锁分析

---

在etcd的v3的client里有一个concurrency的包，里面实现了分布式锁。
源代码在mutex.go

/clientv3/concurrency/session.go

type Session struct {
    client *v3.Client
    opts   *sessionOptions
    id     v3.LeaseID 

    cancel context.CancelFunc
    donec  <-chan struct{}
}

/clientv3/concurrency/mutex.go 分布锁实现分析

// Mutex implements the sync Locker interface with etcd
type Mutex struct {
    s *Session  //上面的Session struct

    pfx   string  //前缀
    myKey string  //key
    myRev int64   //Revision
    hdr   *pb.ResponseHeader
}

func NewMutex(s *Session, pfx string) *Mutex {
	return &Mutex{s, pfx + "/", "", -1, nil}
}

// Lock locks the mutex with a cancelable context. If the context is canceled
// while trying to acquire the lock, the mutex tries to clean its stale lock entry.
func (m *Mutex) Lock(ctx context.Context) error {
    s := m.s  //上面的Session struct
    client := m.s.Client()
    
    //m.pfx是前缀，比如"myresource/lock/"
    //s.Lease()是一个64位的整数值，etcd v3引入了lease（租约）的概念，concurrency包基于lease封装了session，
    //每一个客户端都有自己的lease，也就是说每个客户端都有一个唯一的64位整形值
    
    //m.myKey类似于"myresource/lock/12345"
    m.myKey = fmt.Sprintf("%s%x", m.pfx, s.Lease())
    
    
    //etcdv3新引入的多键条件事务，替代了v2中Compare-And-put操作。
    //etcdv3的多键条件事务的语意是先做一个比较（compare）操作，
    //如果比较成立则执行一系列操作，如果比较不成立则执行另外一系列操作。
    
    //接下来的这部分实现了如果不存在这个key，则将这个key写入到etcd，如果存在则读取这个key的值这样的功能。
    //下面这一句，是构建了一个compare的条件，比较的是key的createRevision（createRevision是表示这个key创建时被分配的这个序号。
    //当key不存在时，createRevision是0。），如果revision是0，则存入一个key，如果revision不为0，则读取这个key。
    //revision是etcd一个全局的序列号,全局唯一且递增，每一个对etcd存储进行改动都会分配一个这个序号，在v2中叫index
    cmp := v3.Compare(v3.CreateRevision(m.myKey), "=", 0) //cmp 比较Revision, 当key不存在时，createRevision是0。
    // put self in lock waiters via myKey; oldest waiter holds lock
    put := v3.OpPut(m.myKey, "", v3.WithLease(s.Lease()))
    // reuse key in case this session already holds the lock
    get := v3.OpGet(m.myKey)
    
    // 如果revision为0，则存入，否则获取
    resp, err := client.Txn(ctx).If(cmp).Then(put).Else(get).Commit()
    if err != nil {
        return err
    }
    // 本次操作的revision
    m.myRev = resp.Header.Revision
    // 操作失败，则获取else返回的值，即已有的revision
    if !resp.Succeeded {
        m.myRev = resp.Responses[0].GetResponseRange().Kvs[0].CreateRevision
    }
    
    ownerKey := resp.Responses[1].GetResponseRange().Kvs
    if len(ownerKey) == 0 || ownerKey[0].CreateRevision == myRev {
        m.hdr = resp.Header
		return nil
        //成功获取锁
    }
    
    //如果上面的code操作成功了，则myRev是当前客户端创建的key的revision值。
    //waitDeletes等待匹配m.pfx （"/myresource/lock/"）这个前缀（可类比在这个目录下的）并且createRivision小于m.myRev-1所有key被删除
    //如果没有比当前客户端创建的key的revision小的key，则当前客户端者获得锁
    //如果有比它小的key则等待，比它小的被删除
    hdr, werr = waitDeletes(ctx, client, m.pfx, m.myRev-1)
    
    // release lock key if wait failed
    if werr != nil {
        m.Unlock(client.Ctx())
    } else {
        m.hdr = hdr
    }
    return werr
}

参考：

---

• https://blog.csdn.net/cadem/article/details/56495834
• https://github.com/coreos/etcd
• https://github.com/jiujuan/tech-collection/blob/master/Etcd/README.md