* [原文链接](https://redis.io/topics/distlock/)
首先,分布式锁在很多需要涉及到不同的进程或线程操作互斥的共享资源的环境中,提供了一种很有用的操作方法.
已经有很多库或博客帖子描述如何使用redis实现分布式锁管理(DLM),但是每个库都是用来不同的方式,但是很多库都是使用一种简单的方法,相比于稍微复杂的设计,安全性保障更低,并不能保证都能达到预期的效果.
针对以上的问题,官方文档将提供一种更权威的算法来使用redis实现分布式锁.我们提出一个名为RedLock的算法,它实现了一个分布式锁管理(DLM),我们认为它比普通的单实例方式更安全. 我们希望社区能分析它,提供反馈,并且使用它作为来实现更复杂或替代设计的起点.
## 实现
在讲述算法之前,这里有一些可供参考的已经是实现的连接.
* [Redlock-rb](https://github.com/antirez/redlock-rb)(ruby)
* [Redlock-py](https://github.com/SPSCommerce/redlock-py) (Python implementation).
* [Aioredlock](https://github.com/joanvila/aioredlock) (Asyncio Python implementation).
* [Redlock-php](https://github.com/ronnylt/redlock-php) (PHP implementation).
* [PHPRedisMutex](https://github.com/malkusch/lock#phpredismutex) (further PHP implementation)
* [cheprasov/php-redis-lock](https://github.com/cheprasov/php-redis-lock) (PHP library for locks)
* [Redsync.go](https://github.com/hjr265/redsync.go/) (Go implementation).
* [Redisson](https://github.com/mrniko/redisson) (Java implementation).
* [Redis::DistLock](https://github.com/sbertrang/redis-distlock) (Perl implementation).
* [Redlock-cpp](https://github.com/jacket-code/redlock-cpp/) (C++ implementation).
* [Redlock-cs](https://github.com/kidfashion/redlock-cs/) (C#/.NET implementation).
* [RedLock.net](https://github.com/samcook/RedLock.net/) (C#/.NET implementation). Includes async and lock extension support.
* [ScarletLock](https://github.com/psibernetic/scarletlock/) (C# .NET implementation with configurable datastore)
* [node-redlock](https://github.com/mike-marcacci/node-redlock/) (NodeJS implementation). Includes support for lock extension.
* 安全和活力保证
我们从三个属性方面来规范设计,从我们的角度来看,这些属性是有效使用分布式锁所需的最小保证.
1. 安全属性:互斥锁,在任何时刻,仅仅只有一个客户端能获得锁;
2. 存活属性A: 无死锁,即使当某个客户端锁定资源后崩溃或者被分离后,最终都有可能获得锁.
3. 存活属性B: 容错,只要大多数的redis节点启动后,客户端都可以获得或释放锁资源;
* 为什么在遇到故障转移时实现不够？
为了理解redis官方想改进的问题,可以从当前大部分基于redis的分布式锁库来进行分析当前的状态.
要想使用redis对一个资源上锁,最简单的办法是在一个redis实例中创建一个key.这个key在创建时,通常会使用redis的过时机制,给它加上有限的生存时间,以保证这个key最终都会被删除.当客户端需要释放资源,它自己可以删除这个key.
从表面上看,这似乎运行的很好,但是却有个问题:在我们的架构中,这有一个单点故障的隐患.当redis主服务宕掉后将会发生什么?很好,我们可以增加一个从服务器!并且在主服务器可用之前把它提升为主服务器.但是不幸的是这不可行.如果那样做的话,我们无法实现互斥的安全性,以为redis的replication机制是异步的.
在这个模型中,会有一个很明显的竞争条件:
1. Client A 获得了Redis主服务器上的锁;
2. 在redis主服务器上的锁还没来得及同步给从服务器时,主服务器宕掉了.
3. redis从服务器被提升为主服务器.
4. Client B获得了已经被Client A上锁的资源,这就违反了安全性。
有时,在某些特殊的情况下,运行的很完美,没有任何问题,好比在一个失败过程中,多客户端可以同时获得这把锁.如果是这种情况,你可以基于主从复制的解决方案.否则的话我们建议按照这篇文档的描述来实现.
# 基于单例的正确实现
在尝试克服上面所描述的单例时遇到的限制之前,让我们来检查下,在这种简单的实例中怎么做才是正确的.因为这实际上是一个可行的解决方案,在应用中,不时的竞争条件是可被接受的,因为锁定到一个单一的实例是我们用来描述分布式算法的基础。
获取一把锁,可以通过以下的方式:
```
SET resource_name my_random_value NX PX 30000
```
这个命令仅仅在当key不存在时候才能设置成功(NX选项),使用PX选项设置在30000ms后过期,过期后将自动删除.key设置的值为一个随机数.对于所有客户端和所有的锁请求这个value都必须唯一.基本的是这个值被用来通过安全的方式释放锁,通过这个脚本,告诉redis:只有当key存在,并且key中存在的值是我所期望的值得时候才能被删除.这是通过以下的lua脚本来实现的:
```
if redis.call("get",KEYS[1]) == ARGV[1] then
return redis.call("del",KEYS[1])
else
return 0
end
```
为了避免删除由另一个的客户端创建的锁.例如,客户端可能获得锁,在某些操作中,阻塞的时间超过锁的有效时间(key的过期时间),然后删除其他客户端已经获得的锁,.仅使用del是不安全的,当一个客户端可能删除另一个客户端的锁.通过上面的脚本,每个锁都是通过随机数"签名"的,因此只有设置锁的客户端才能删除这把锁.
举例:
```
import "github.com/gomodule/redigo/redis"
func redisTest(){
println("redis test")
con := ConnectServer("127.0.0.1:6379")
if nil == con{
fmt.Println("Connect 127.0.0.1:6379 error")
return
}
//延迟关闭
defer con.Close()
//get lock
taskId := 1314
ok := getlock(con, taskId)
if ok{
//获取到锁,dosomething
fmt.Println("Get lock ok")
releaseLock(con, taskId)
} else {
fmt.Println("Get lock failed!")
}
}
func releaseLock(con redis.Conn, taskId int) bool{
_, err := con.Do("del", strconv.Itoa(taskId))
return nil == err
}
func getlock(con redis.Conn, taskId int) bool{
//检查是否存在key
s, err := redis.String(con.Do("GET", strconv.Itoa(taskId)))
if nil == err{
fmt.Println(s)
return false//锁已经被占用
} else {
_, er := con.Do("set", strconv.Itoa(taskId), strconv.Itoa(rand.Int()))
if nil ==er{
fmt.Println("Set key ok")
return true
} else {
fmt.Println("Set key failed!")
}
}
return false
}
```
