本系列都是翻译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 set resource_name random_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[1]) == ARGV[1] then return redis.call("del",KEYS[1]) else return 0 end
对于Client 1 本身有一个ARGV[1] 如果相等 才删除。这种很好的避免了被其他客户端删除这个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的一个分布式锁解决的问题。
