2020-11-06:红锁的设计思想？

前言

每日一题专栏

红锁的设计思想？

一、锁丢失

Redis的master节点上拿到了锁；

但是这个加锁的key还没有同步到slave节点；

master故障，发生故障转移，slave节点升级为master节点；

导致锁丢失。

二、持有同一把锁（竞态模型场景）

为了避免Redis宕机引起锁服务不可用, 需要为Redis实例(master)增加热备(slave)，如果master不可用则将slave提升为master。这种主从的配置方式存在一定的安全风险，由于Redis的主从复制是异步进行的， 可能会发生多个客户端同时持有一个锁的现象。

竞态模型：

1、Client A 获得在master节点获得了锁

2、在master将key备份到slave节点之前，master宕机

3、slave 被提升为master

4、Client B 在新的master节点处获得了锁，Client A也持有这个锁。

三、脑裂问题

四、解决方案，算法如下：

简单来说是过半机制。

一个客户端需要做如下操作来获取锁：

1、获取当前时间（单位是毫秒）。

2、轮流用相同的key和随机值在N个节点上请求锁，在这一步里，客户端在每个master上请求锁时，会有一个和总的锁释放时间相比小的多的超时时间。比如如果锁自动释放时间是10秒钟，那每个节点锁请求的超时时间可能是5-50毫秒的范围，这个可以防止一个客户端在某个宕掉的master节点上阻塞过长时间，如果一个master节点不可用了，我们应该尽快尝试下一个master节点。

3、客户端计算第二步中获取锁所花的时间，只有当客户端在大多数master节点上成功获取了锁（在这里是3个），而且总共消耗的时间不超过锁释放时间，这个锁就认为是获取成功了。

4、如果锁获取成功了，那现在锁自动释放时间就是最初的锁释放时间减去之前获取锁所消耗的时间。

5、如果锁获取失败了，不管是因为获取成功的锁不超过一半（N/2+1)还是因为总消耗时间超过了锁释放时间，客户端都会到每个master节点上释放锁，即便是那些他认为没有获取成功的锁。