在一个分布式系统中,只要涉及到多个节点访问同一个公共资源的时候,就需要加锁来实现互斥,从而达到线程安全的问题。
但是呢,分布式系统不同一些,因为分布式系统部署在不同的服务器上,很可能大量的请求打到不同的服务器上,如果没有分布式锁,每台服务器就都判断成功,就导致了资源被多次消费了。
所以有了分布式锁的概念。 分布式锁:本质就是使用一个公共的服务器(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节点,而是写入多个。最后当加锁成功的数量超过集群数量的一半的时候,就视为加锁成功。
所以即使有些节点挂了,也不影响锁的正确性。