分布式锁.md

分布式锁

第一种是基于数据库实现
第二种是基于缓存系统去实现（典型代表是使用Redis实现的锁服务）
第三种是基于分布式一致性算法实现（典型代表为Zookeeper）
提供个其他思路，解决需要加锁的问题，也许更好的方式是绕过加锁的环节。比如说两个请求要同时访问一个资源，如果可以把他们串行化（比如放到同一个队列来处理）。当然，只是提供一个思路，这个要看业务具体的特点。

基于数据库的实现，大概也是两个思路。第一种是悲观锁（select xxx for update），第二种是乐观锁。

举个例子：

比如某进程获得到的节点序号为 /zk_lock/003，然后所有的节点列表为[/zk_lock/001，/zk_lock/002，/zk_lock/003]，则对 /zk_lock/002 这个节点添加一个事件监听器。
如果锁释放了，会唤醒下一个序号的节点，判断是否自己的节点序号是最小。
比如 /zk_lock/001 释放了，/lock/002 监听到时间，此时节点集合为[/zk_lock/002，/zk_lock/003]，则 /lock/002 为最小序号节点，获取到锁。

优点：

在redis上面设置一个key作为锁

使用set key value 作为锁的标记位，然后expire key 10s 设置key的有效期

问题：这个方案的问题是，是通过两条语句执行的，不能保证原子性.
SET key value NX PX milliseconds
```
key: 资源的key,标识一种资源。

value: 此值必须在所有进程和所有获取锁的请求中都是唯一的。

NX: 该命令仅在key不存在时才设置。

PX milliseconds: 过期时间,单位为毫秒。
```
这个方案是通过一条命令设置key的value，以及key的有效期，这样可以保证是一个原子的操作。

释放 :
```
if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end
```
这种方案解决不了的问题是：

如果在一个redis的集群中，当在master的节点完成了这个操作，但是由于redis是异步复制的，slave的节点不指定会马上收到通知的数据。如果master立刻宕机，会导致上锁失败。
redlock 方案

对于在集群中的枷锁redis给的方案是redlock，它的基本思路就是为锁准备多个独立的节点，在锁过期时间内只要超过半数获取到锁，就算成功，避免redis主从切换的时候，数据丢失。

总结一下，分布式锁是解决多个进程同时访问临界资源的常用方法，在分布式系统中非常普遍，常见的实现方式是基于数据库，基于 Redis。

参考：