分布式Redis的分布式锁Redlock_IDC模块化数据中心

引言

之前自己在用redis来实现分布式锁的时候都是基于单个Redis实例，也就是说Redis本身是有单点故障的，Redis的官方文档介绍了一种"自认为"合理的算法，Redlock来实现分布式Redis下的分布式锁。

Martin Kleppmann写了一篇文章分析Redlock。然后redis的作者写了一篇反驳的文章这里。加油。

Redlock实现库

Java Redisson Star 9458 C# RedLock.net Star 259 Go redsync.go Star 249

虽然后面的算法是一样的，不过这个点赞数确实服。

单点Redis锁

先简单回顾一下单点的Redis锁是怎么实现的。

获取锁

SET resource_name my_random_value NX PX 30000

客户端A在Redis上设置一个特定的键值对，同时给一个超时时间(避免死锁)。其他客户端在访问的时候先看看这个key是否已经存在，并且值等于my_random_value。如果已存在就等待，否则就获取成功，执行业务代码。resource_name和my_random_value是所有客户端都知道并且共享的。

释放锁

if redis.call("get",KEYS[1]) == ARGV[1] then return redis.call("del",KEYS[1])else return 0end

对比key获取到的对应的value是否相等，如果相等，就删除(释放)，否则就返回失败。

之前也写过一篇文章。

单点Redis锁的缺陷

这个缺陷其实很明显，如果只有一个Redis实例，这个挂了，所有依赖他的服务都挂了。显然不太适合大型的应用。

简单的Redis主从架构碰到的问题

为了避免单点故障，我们给Redis做一个Master/Slave的主从架构，一个Master，一台Slave。下面就会碰到这么一个问题。下面是使用场景。

客户端A在Master上获取到一个锁。 Master把这个数据同步到Slave的时候挂了(因为Master和Slave之间同步是异步的)。 Slave变成了Master。客户端B通过相同的key，和value获取到锁。分布式锁失效

Redlock算法

假设我们有N(假设5)个Redis master实例，所有节点相互独立，并且业务系统也是单纯的调用，并没有什么其他的类似消息重发之类的辅助系统。下面来模拟一下算法：

1.客户端获取服务器当前的的时间t0，毫秒数。