python etcd3模块的lock使用
观察lock的加解锁影响
在python中已经自带了分布式锁的实现方式，下面我们尝试一下加锁与解锁的流程
在运行该demo同时也对lock对应的key进行watch，观察其变化，注意python-etcd3在实现分布式锁的时候，采用的key需要加上prefix：
在这里插入图片描述
结果如下：
当获取到锁的时候value改变，当release的时候锁value为空，此时cancel掉对当前key的watch
使用
下面的例子中，我们在程序1中先获取分布式锁，之后启动程序2进行尝试获取锁，根据is_acquired结果可知，没有获取成功。
注意，这里无论try-lock的key是不是和其他程序一样，都会失败
因为底层判断是否获取到锁，是看同目录下自己操作的revision是不是最小。而底层的目录都是/locks。
实现学习
尽管etcd3模块集成了分布式锁，但是我们可以学习一下其实现方式，从而熟悉etcd的接口，以后可以借此组合出其他的应用。
我们需要依赖etcd的如下特性：
-
lease机制，为存储的kv设置租约，当租约到期，kv失效删除，同时也支持续租
-
revision机制，每一个key带有一个revision属性，etcd每进行一次事务，对应的全局revision都会+1，因此每个key对应的revision属性值都为全局唯一，比较revision大小可以知道写操作的顺序（需要验证一下）
如下，我们顺序进行两次put操作：
import etcd3
import json
import time
etcd = etcd3.client(host='127.0.0.1', port=2379)
print(etcd.put('demo/key1', 'doot'))
print(etcd.put('demo/key2', 'doot'))
结果如下，可以看到revision也是递增的
header {
cluster_id: 17237436991929493444
member_id: 9372538179322589801
revision: 71
raft_term: 11
}
header {
cluster_id: 17237436991929493444
member_id: 9372538179322589801
revision: 72
raft_term: 11
}
- 在实现分布式锁时，多个程序同时枪锁，根据revision值大小依次获得锁，避免惊群效应
- prefix机制，根据前缀目录获取该目录下所有的key以及对应的属性（key、value、revision）
- watch机制，watch某个key或者目录，当被watch的key或者目录发生变化，客户端收到通知
实现逻辑
1、客户端连接etcd，以lock/mylock为前缀创建全局唯一的key
假设第一个client对应的key为：key = lock/mylock/uuid1
第二个client对应的key为：key = lock/mylock/uuid2
每个客户端分别为自己的key创建lease，租约的ttl取决于业务耗时，这里假设为15s
2、创建定时任务作为续租的心跳
当一个client持有锁期间了，其他客户端只能等待，为了避免等待期间租约失效，客户端需要创建一个定时任务作为心跳进行续约。
若持有锁期间client崩溃，心跳停止，key会因为租约到期而被删除，从而锁释放，避免死锁
3、client将自己全局唯一的key写入etcd
进行put操作，将1中创建的key与lease绑定写入etcd。
根据revision机制，假设两个client的put操作返回的revision分别为1，2；客户端需要记录revision用以接下来判断自己是否获得锁
4、client判断是否获得锁
client以前缀lock/mylock读取kv列表，判断自己的key的revision是否为当前列表中最小的；
如果是，认为获得锁；
如果不是，监听列表中前一个revision比自己小的key的删除事件，一旦监听到删除事件或者因lease失效而删除的事件，则自己获得锁
5、执行业务
获得锁后，操作共享资源，执行业务代码
6、释放锁
完成业务流程后，删除对应的key，释放锁。
参考
http://www.xuyasong.com/?p=1789#_ETCD-2
