RedLock是Redis作者Antirez提出的分布式锁 算法 ，专门解决主从架构下锁丢失的问题。
单机Redis做分布式锁有单点故障风险。主从架构也不保险:客户端在主节点加锁成功，主节点还没把锁数据同步到从节点就挂了，从节点晋升为新主节点，锁数据压根没同步过来。这时候另一个客户端来加锁，也能成功，两个客户端同时拿到锁，数据就乱了。
Redlock的思路是用多个独立的Redis实例 投票 ，只有拿到大多数节点的锁才算加锁成功。即使部分节点故障，锁的安全性依然有保障。
RedLock实现原理：
部署5个独立的Redis实例，注意是完全独立的，不需要主从复制，不需要哨兵，也不是Redis Cluster，5个实例之间没有任何数据同步。
加锁流程：
1，客户端记录当前时间戳t1
2，依次向5个Redis实例发送SET lock_key uuid EX 30 NX命令
3，每个请求设置较短的超时时间，比如5-50ms，某个实例超时就跳过。
4，统计成功加锁的实例数量
5，获取当前时间戳t2，计算加锁总耗时t
6，如果成功数量 >= 3且 t < 锁的过期时间，加锁成功。
7，否则向所有实例发送解锁请求
解锁流程：
向所有5个实例发送DEL命令，不管之前是否加锁成功
加锁和解锁命令跟普通Redis分布式锁一样，都是SET EX NX 加锁，Lua脚本解锁。
RedLock一定安全吗？
答：不一定。Martin Kleppmann对RedLock提出过质疑：
可能不安全场景：
1)客户端1拿到Redlock
2)客户端1发生长时间GC，进程被暂停
3)GC期间锁过期了
4)客户端2趁机拿到锁
5)GC结束，客户端1不知道锁已经过期，继续执行业务
6)两个客户端同时操作临界资源
除了GC，时钟跳变也是隐患。Redlock依赖各节点的系统时间来计算锁的有效期，如果某个节点的时钟突然往前跳了，锁就会提前过期。
Antirez 回应说可以用 fencing token机制来解决，但 Redis 本身并不支持fencing token，需要业务端自己实现。
生产环境的选择：
Redlock的实现成本不低:
-
需要部署至少5个独立实例，资源开销大
-
加锁要依次访问多个节点，延迟比单机高
3)极端情况下还是有问题
所以大多数业务场景还是用主从+哨兵的方案，配合Redisson的看门狗续期。只有对锁的可靠性要求极高的场景才考虑Redlock，比如金融交易、库存扣减。
如果确实需要强一致性的分布式锁，可以考虑ZooKeeper 或者etcd，它们基于Paxos/Raft共识算法，一致性保证比Redis更强。
提问：
1，提问: Redlock为什么推荐部署5个实例而不是3个?
回答:5个实例允许最多2个节点故障还能正常工作，容错能力更强。3个实例只允许1个故障，风险太大。而且5个是奇数，投票时不会出现平票的情况。实例数再多性能就太差了，5个是性能和可靠性的平衡点。
2，提问:如果Redlock加锁成功了，但执行到一半有个Redis实例重启了，会有什么问题?
回答:要看这个实例是否开启了AOF持久化。如果没开，重启后锁数据丢失，其他客户端可能在这个实例上加锁成功，配合其他实例可能凑够大多数票。所以用 Redlock 的实例必须开启AOF并且设置fsync=always，保证每次写入都落盘。代价是性能会下降。
3，提问:Martin Kleppmann提到的 fencing token是什么?怎么实现?
回答:fencingtoken是一个单调递增的序列号，每次加锁成功时分配一个token。客户端操作共享资源时带上token，资源端只接受token大于等于上次见过的最大值的请求。这样即使老客户端的锁过期了还在执行，它的token比新客户端小，请求会被拒绝。实现需要存储端支持版本比较，比如数据库的乐观锁、ZooKeeper的版本号。
4，提问:ZooKeeper 和 Redis 做分布式锁各有什么优劣?
回答:ZooKeeper用临时顺序节点实现，基于ZAB协议保证一致性，可靠性比Redis高，客户端宕机会话断开锁自动释放不需要考虑续期。缺点是性能比Redis差一个数量级，QPS大概几千，Redis能到十万级。Redis性能好但一致性弱，适合大多数互联网场景。金融、交易这种对一致性要求极高的场景用ZooKeeper更稳。