[翻译]利用REDIS来搭建可靠分布式锁的提议
本系列都是翻译REDIS作者的博文另外加上我自己的一点点理解希望有问题大家一起讨论http://antirez.com/news/77 原文地址
在利用REDIS做分布式锁时基本持有2种观点： 1种认为这是非常 快速的 很伟大的案例 认为redis解决了一个非常难解决的问题，但是另一方面却不是这样的观点，认为利用REDIS做分布式锁是非常恼火的，完全是在错误的使用REDIS
作者认为2者都正确 也就是作者认为2者都说的过去那我们来看看作者是怎么阐述的：
Safety and Liveness guarantees
作者提出了3点要求 对于一个可靠的分布式锁服务系统：
1) 安全属性： 锁竞争 任何时候 只有一个锁能够提供服务
2) Liveness A：无死锁发生即使可能有一个客户端锁住一个资源崩溃了或者被隔离了最终系统还是能够获得锁
3) Liveness B： 错误容忍 只要主Redis上线 客户端就能够取得和释放锁。
Why failover based implementations are not enough
一般而言 实现的模式如下：
if redis.get(resource)==false
setresource_namerandom_value px 3000
do_something()
if(redis.get(resource)==true)
redis.del(resource)
利用REDIS来实现一种带有时间阀值的KEY 来保证了条款2的不会出问题
但是3是无法满足的。 如果REDIS master 挂掉 了 怎么办这点很恼火：
没有办法满足服务哦了解REDIS都知道REDIS还是推出了异步的主从服务机制，也就是说redis本身而言 master挂了 还可以调用从节点但是注意这里是异步 也就是不安全，可能会导致在传给slave之前主机down掉那就悲催这样之后调用从机节点就没法保证了怪不得了作者准备新加一个WAIT命令来做同步复制功能 这个功能的确需要~！不扯这里了看看在现有的环境下作者又会给出什么算法呢？
1) 为了防止Key 被其他客户端删除掉作者提出了一个想法就是key相同 value 采用signal的方法 value采用一个随机值【对于每个客户端而言】
if redis.call("get",KEYS) == ARGV then
return redis.call("del",KEYS)
else
return 0
end
对于Client 1 本身有一个ARGV 如果相等 才删除。这种很好的避免了被其他客户端删除这个key。
但是前面提出的那个问题主从问题还是不能很好的解决掉。 如果主节点挂掉从节点上去之后 没有那个KEY下面是我写的一个伪代码部分 仅供参考
伪代码如下：
Thread 1
task_have_done true
if redis.getLock(key)==true
do_Task()
set task_have_done true
else
sleep()
try_get_lock()
Thread 2
if Keepalive_Master()==true
{
if task_have_done true
redis.unlock(key)
continue;
}
else
change_Master
if task_have_done && redis.get(key)==myValue
del key
if redis.get(key)==NULL
SET KEY my_value px_last_time
后面作者提出了在分布式环境下的REDIS 获取分布式锁问题这点留到以后分析因为我的感觉锁这个东西占用不了很大的空间 所以目前估计还用不着嘿嘿
这就是目前REDIS的一个分布式锁解决的问题。
页:
[1]