分布式锁是控制分布式系统之间同步访问共享资源的一种方式。
其典型的使用场景为：
不同系统或者是同一系统的不同主机之间共享了一个或一组资源，那么访问这些资源的时候，需要通过一定的互斥手段来防止彼此的干扰，以保证一致性。
1. 使用Redis实现分布式锁
* WATCH, MULTI, EXEC, DISCARD事务机制实现分布式锁
Redis支持基本的事务操作
MULTI
some redis command
EXEC
以上被MULTI和EXEC包裹的redis命令，保证所有事务内的命令将会串行顺序执行，保证不会在事务的执行过程中被其他客户端打断。
而WATCH命令能够监视某个键，当事务执行时，如果被监视的键被其他客户端修改了值，事务运行失败，返回相应错误（被事务运行客户端在事务内修改了值，不会造成事务运行失败）。
运用Redis事务所支持的以上特性，可以实现一个分布式锁功能。Python代码如下：
# -*- coding: utf-8 -*-
def acqure_lock_with_watch(conn, lockname, acquire_timeout=10):
pipe = conn.pipeline()
end = time.time() + acquire_timeout
lockname = 'lock:' + lockname
while time.time() < end:
try:
pipe.watch(lockname)
pipe.multi() # 开启事务
# 事务具体内容，对lockname的值进行更新
pipe.execute()
return True
except redis.exceptions.WatchError:
# 事务运行期间，有其他客户端改变了lockname的值，抛出异常，进行重试操作
pass
return False
通过WATCH命令监视某个键，当该键未被其他客户端修改值时，事务成功执行。当事务运行过程中，发现该值被其他客户端更新了值，任务失败，进行重试。
* SETNX实现分布式锁
SETNX：当指定键不存在时，向Redis中添加一个键值对。Redis客户端保证对统一键名称，多个客户端同时设置其值时，只有一个客户端能够设置成功的原子性。
# -*- coding: utf-8 -*-
def acquire_lock_with_timeout(
conn, lockname, acquire_timeout=10, lock_timeout=10):
identifire = str(uuid.uuid4())
lockname = 'lock:' + lockname
lock_timeout = int(math.ceil(lock_timeout))
end = time.time() + acquire_timeout
while time.time() < end:
if conn.setnx(lockname, identifire): # 以锁名称为键，uuid的值为值，redis服务器setnx保证了只能有一个客户端成功设置键的原子性
conn.expire(lockname, lock_timeout) # 设置键的过期时间，过期自动剔除，释放锁
return identifire
elif not conn.ttl(lockname): # 当锁未被设置过期时间时，重新设置其过期时间
conn.expire(lockname, lock_timeout)
time.sleep(0.001)
return False
以上，利用SETNX的原子特性，和Redis的键过期特性，实现了自动过期释放的分布式锁。
* 锁的释放
# -*- coding: utf-8 -*-
def release_lock(conn, lockname, identifire):
pipe = conn.pipeline(True)
lockname = 'lock:' + lockname
while True:
try:
pipe.watch(lockname) # 监视锁的键，在锁释放过程中改变了键的值时得到相应通知
if pipe.get(lockname) == identifire: # 检查客户端是否仍然持有该锁
pipe.multi()
pipe.delete(lockname) # 删除键，释放锁
pipe.execute()
return True
pipe.unwatch()
break
except redis.exceptions.WatchError:
pass # 释放锁期间，有其他客户端改变了键值对，锁释放失败，进行循环
return False
锁释放的过程，首先检查客户端是否仍然持有该锁，如果持有，则在事务中删除键值对，释放锁的所有权。
2. 使用Memcached实现分布式锁
Memcached的add命令，当指定的key不存在时，进行添加，且保证了执行的原子性。利用该特性，可以实现一个分布式锁实现。
def acquire_lock_with__memcached_timeout(
conn, lockname, acquire_timeout=10, lock_timeout=10):
identifire = str(uuid.uuid4())
lockname = 'lock:' + lockname
lock_timeout = int(math.ceil(lock_timeout))
end = time.time() + acquire_timeout
while time.time() < end:
# 过期时间保证了客户端崩溃时仍能在超过过期世家后正常释放锁
# 以锁名称为键，uuid的值为值，memcached服务器add保证了只能有一个客户端成功设置键的原子性
if conn.add(lockname, identifire, lock_timeout):
return identifire
time.sleep(0.001)
return False
释放锁时，删除指定key的键即可。
3. 使用ZooKeeper实现分布式锁
相较于使用redis和memcached实现的锁，zk利用其高级特性，能够实现更复杂的锁特性。
-
排它锁
排它锁，又称写锁或独占锁。如果事务T1对对象O1加了排它锁，那么整个加锁期间，只允许事务T1对O1进行读取和更新操作，其他任何事务都不能对该数据对象进行任务读写操作，直到T1释放了排它锁。
以上介绍的使用redis和memcached实现的分布式锁都属于排它锁。
获取锁
ZooKeeper实现分布式锁利用了其临时子节点的如下特性：
在/exclusive_lock节点下创建临时子节点/exclusive_lock/lock，zk会保证在所有的客户端中，最终只有一个客户端能够创建成功，即可以认为该客户端获得了锁。同时，虽有没有获取到所得客户端需要到/exclusive_lock节点上注册一个子节点变更的Watcher监听，以便实时监听到lock节点的变更情况。
释放锁
因为在获取锁时，创建的是一个临时节点/exclusive_lock/lock，因此在如下情况，都有可能释放锁：
- 获取锁的机器发生宕机，临时节点被zk移除
- 正常执行业务逻辑后，客户端主动删除临时节点
无论什么情况下，lock节点被移除，zk都会通知所有在/exclusive_lock节点上注册了子节点变更的Watcher监听的客户端。这些客户端在收到通知后，重新发起分布式锁的获取流程。
-
共享锁
共享锁又称读锁。如果事务T1对数据对象O1加上了共享锁，那么当前事务只能对O1进行读取操作，其他事务也只能对这个数据对象加上共享锁，直到该数据对象上的所有共享锁都被释放。
而更新操作只能在当前没有任何事务进行读写操作的情况下进行。
获取锁
当需要获取共享锁是，所有客户端到/shared_lock节点下面创建一个临时顺序节点，/shared_lock/[hostname]-请求类型（W | R）-序号，该节点代编了一个共享锁。
如果是读请求，则创建/shared_lock/192.168.0.1-R-000000000001；
如果是写请求，则创建/shared_lock/192.168.0.1-W-000000000001；
判断读写顺序
- 在创建完监听后，获取/shared_lock节点下的所有子节点，对该节点注册子节点变更的Watcher监听
- 确定自己的节点序号在所有子节点的顺序
- 对于读请求：
如果没有比自己序号小的子节点，或是所有比自己序号小的子节点都是读请求，那么表明自己已经成功获取到了共享锁，执行读取逻辑。
如果比自己序号小的子节点中有写请求，那么进入等待。
- 对于写请求：
如果自己不是序号最小的子节点，那么进入等待。
- 收到Watcher通知后，重复步骤1-4
释放锁
释放锁，删除对应的数据节点即可。
参考资料：
《从Paxos到ZooKeeper分布式一致性原理与实践》 - 倪超 著
https://redis.io/topics/transactions
http://redisbook.readthedocs.io/en/latest/feature/transaction.html
