Redis——分布式锁

在一个分布式系统中，只要涉及到多个节点访问同一个公共资源的时候，就需要加锁来实现互斥，从而达到线程安全的问题。

但是呢，分布式系统不同一些，因为分布式系统部署在不同的服务器上，很可能大量的请求打到不同的服务器上，如果没有分布式锁，每台服务器就都判断成功，就导致了资源被多次消费了。
所以有了分布式锁的概念。 分布式锁：本质就是使用一个公共的服务器（Redis、MySQL、或其他的服务器），来记录加锁的状态。 这里直讲用Redis实现分布式锁。

分布式锁的基础实现

分布式锁其实很简单，就是在Redis中通过一个键值对来完成的。
例如下面的场景：在抢票的场景下，现在车站提供了若干车次，每个车次的票数是固定的。 现在存在多个服务器，都需要处理买票的逻辑：查询车次的票数，判断票数是否大于0，如果大于0，票数–。

显然，要通过加锁来避免线程安全的问题，此时我们引进了一个Redis，作为锁的管理

此时，如果买票服务器1尝试买票，需要先访问Redis，然后再Redis上设置一个键值对。 （例如 key —— 车次 value—— 设置为1），当键值对设置成功的时候，就代表没有节点对001车次加锁，就可以对数据库进行操作，当操作完成的时候，将键值对删除掉。

在加锁的过程中，即使有服务器2来尝试买票，会发现Redis上已经存在该车次的key了，所以只能阻塞。

所以根据上面的场景用Redis来操作的话，就很简单了，直接setnx操作，如果key不存在就创建，存在则失败返回。

过期时间

但是有一个问题： 当服务器1加锁之后，开始处理买票的逻辑时，如果服务器1宕机了，就会导致删除key不能执行，其他服务器不能在这个车次上进行买票逻辑了，所以需要在此基础上加上一个过期时间。

所以通过用Redis的set nx ex来完成，注意这里不能setnx之后，再设置一个过期时间，因为Redis和MySQL不同，Redis即使使用了事务，也不能保证这2个操作一起成功（这是和MySQL不同的地方），所以很可能出现一种情况：setnx成功了，但是expire失败了，一样导致不能成功释放掉锁。

检验ID

这时候其实还有一个很大的问题， 我们设置键值对的时候，是key——001，vlaue——1， 这是否在分布式系统中有问题呢？？
比如：服务器1写入001:1的键值对的时候，其他服务器是可以对它进行操作的，这很不合理。
所以键值对应该不能简单的设置为1，应该设置为服务器的编号，比如key——001，value——服务器1，当我们要删除键值对的时候，会先去判断当前删除key的服务器是否是加锁时候的服务器，如果是就删除，否则不能删除。

这里提供一段伪代码，流程如下：

String key = [要加锁的资源 id];
String serverId = [服务器的编号];
// 加锁, 设置过期时间为 10s
redis.set(key, serverId, "NX", "EX", "10s");
// 执⾏各种业务逻辑, ⽐如修改数据库数据. 
doSomeThing();
// 解锁, 删除 key. 但是删除前要检验下 serverId 是否匹配. 
if (redis.get(key) == serverId) {redis.del(key);
}

引入Lua

很明显，上述的代码不是原子的，所以为了解决这个问题，又引入了Lua脚本来实现原子的问题。

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

引入Watch dog

但是上面的实现方案还有问题，过期时间设置为多少合适呢？？

• 如果设置少了，很可能出现，任务没执行完，key被删除的情况。 如果过期时间设置的长，也无法保证没有提前失效的场景。
• 而且设置的长了，如果服务器挂了，其他的服务器也获取不到锁

因此结合上述的问题，引入了Watch dog的概念，本质就是在加锁的服务器上的一个单独的线程，通过这个线程对加锁实现"动态续约"

假设过期时间为10s，我们的Watch dog设置为3s检测一次，那么当3s时间到的时候，Watch dog会去看当前任务是否完成

• 如果任务完成，则直接通过Lua脚本来删除key
• 如果任务没有完成，将过期时间延长

所以就解决了，即使服务器挂了，Watch dog也挂了，key很快就会被删除掉，其他服务器也可以获取到锁了。

引入Redlock算法

Redis实际上是通过集群的方式来部署的，所以有可能出现以下的问题。

服务器1向master节点进行加锁操作，这个写入刚刚完成，但是maser改了，slave节点升级为新的maseter节点，由于数据还没有同步，此时服务器1的加锁操作是否就形同虚设了呢？ 服务器2就可以给新的master写入key了。

所以为了解决上面的问题，引入了Redlock算法。
Redlock算法：在加锁的时候，不再只写给一个Redis节点，而是写入多个。最后当加锁成功的数量超过集群数量的一半的时候，就视为加锁成功。

所以即使有些节点挂了，也不影响锁的正确性。