“孤独被染上童话底色~”?
? ? ? ? 我们谈到“锁”这个概念,你一定会想到这一定是涉及到了线程安全的问题。当一个进程内的不同线程,需要访问同一资源(共享资源)时,如果进行不加锁,就会出现线程安全的问题。在分布式系统中,每个进程都是独立运行于一台独立的机器中的,当它们对共享资源进行访问时,如果不进行限制,也会出现类似的安全问题。但,之前的,仅仅运用于进程内的锁,不会再起任何作用,其次,分布式系统中多个进程间的执行顺序也具有不确定性。
——前言
? ? ? ? 在分布式系统中,涉及到的多个节点访问共享资源的问题时,也需要“锁” 来做互斥控制,避免类似“线程”安全的问题。但在分布式系统中使用的不再是普通的锁机制,诸如:java 的 synchronized 或者 C++ 的 std::mutex等。这样的锁都是只能在当前进程中?效, 在分布式的这种多个进程多个主机的场景下就?能为?了.
本质上就是使??个公共的服务器, 来记录 加锁状态。
? ? ? ? 这个公共的服务器可以是Redis,可以是Mysql、ZooKeeper等组件,还可以 是我们??写的?个服务。
?
? ? ? ? 本标题同Redis相关,所以咱们使用的公共服务器基于Redis实现。本质上的思路十分简单,就是利用Redis内部的键值对,来识别锁的信息。
? ? ? ? 当我们引入分布式锁之后:
? ? ? ? 设置键值对的逻辑是,不存在就设置,存在就设置失败。
? ? ? ? 这同Redis中的一个命令十分契合:setnx?
? ? ? ? 使用setnx确实可以得到一种“加锁”的效果,如果想要解锁,就使用Redis中的DEL命令。
????????
? ? ? ? 如果某个服务器完成了setnx,实现了加锁的效果。但突然,该服务器断电,程序崩溃了!也就是说,现目前该服务器无法将这键值对删除,解除对资源的占用,那么其他服务器就无法得到锁。
? ? ? ? 所以,正常情况下会给key设置过期时间,一旦时间到了,就会被自动删除掉。
? ? ? ? 我们可以使用例如: set nx ex的命令完成设置。注意,这是一条命令!如果是使用 setnx expire的方式,就算Redis是原子的,它仅仅是保证该命令被执行,至于命令执行正确与否,它是压根不关心的。不同于,Mysql事务翻滚、回溯。
? ? ? ? 所谓的加锁,就是在公共Redis器中设置键值对,所谓解锁就是在这个Redis上将这个键值对删除。
? ? ? ? 那有没有一种可能,换句话说失误,服务器1设置的键值对,会被服务器2删除呢 ?答案是肯定的!因为压根没有任何身份标识,到底是谁设置的这个键值对。
? ? ? ? 所以,为了解决这个问题,一般会引入校验机制。我们可以在键值对的Value设置编号,每一个服务器都有一个编号,设置键值对的时候就将自己的编号写入Value中。
? ? ? ? 一旦Redis检测到DEL命令时,首先就需要判断发起该操作的服务器id,是否同键值对设置时,填入的Value一致。如果是,才会真正执行,不是就会失败。
????????即:在服务器1中的线程A执行DEL后,线程B执行DEL前,加入一个新的服务器2执行加锁操作,此时因为线程A已经把锁释放了,所以新服务器2加锁是成功的。但紧接着,线程B又执行DEL操作,把服务器2的加锁给释放了。
? ? ? ? 归根到底,出现这个问题的原因就在于GET、DEL不是原子性的,中间被“插队”了。解决这个问题的方法很多:比如说Redis自身提供的事务。但在实际中往往会采用使用lua脚本,这更好的方案。
? ? ? ? lua是一个编程语言,作为Redis中内嵌的语言。
? ? ? ? 使用lua编写的脚本传递到Redis服务器上,可以通过客户端来控制Redis执行该脚本。Redis执行lua脚本的过程,是原子的。就相当于把lua中的所有命令当成一条命令。?下面是一份伪代码:
# 获取KEYS[1]Value
if redis.call('get',KEYS[1]) == ARGV[1] then
return redis.call('del',KEYS[1]) # 执行删除
else
return 0
end;
? ? ? ? 在上述方案中,我们给Key设置了一个过期时间。当时间超过设定时间时,即便服务器自身不对该Key进行释放,redis也会对这个键值对进行删除。
? ? ? ? 但有时也存在一定的可能,当前 任务可能还没有执行完,key 就先过期了。这就导致锁提前失效。所以到底设置多长的时间,作为过期时间是值得考虑的。所以,更好的方式是“动态续约”,初始情况是一个值,根据任务完成度,会在这个值的基础上延长过期时间。? ??
????????即watch dog, 本质上是加锁的服务器上的?个单独的线程, 通过这个线程来对锁过期时间进? "续约"。这是一个广义的概念,在很多场景,针对过期问题都会引入看门狗机制。注意, 这个线程是业务服务器上的, 不是 Redis 服务器的.
????????实践中的 Redis ?般是以集群的?式部署的 (?少是主从的形式, ?不是单机). 那么就可能出现以下?较极端的?冤种情况:
????????服务器1 向 master 节点进?加锁操作. 这个写? key 的过程刚刚完成, master 挂了;
slave 节 点升级成了新的 master 节点. 但是由于刚才写?的这个 key 尚未来得及同步给 slave 呢, 此时 就相当于 服务器1 的加锁操作形同虚设了。
????????为了解决这个问题, Redis 的作者提出了 Redlock 算法:
????????如果给某个节点加锁失败, 就?即再尝试下?个节点。当加锁成功的节点数超过总节点数的?半, 才视为加锁成功。
? ? ? ? 所以,当一个Master节点挂了,并且没有将新到的数据同步给从节点时,也不会影响加锁的正确性了。
?????????同理, 释放锁的时候, 也需要把所有节点都进?解锁操作。这种“少数服从多数”的策略操作的思想,也同哨兵机制选取leader,集群选取新的主节点相似。
? ? ? ??实际开发中, 我们也并不会真的??实现?个分布式锁. 已经有很多现成的库帮我们封装好了, 我们直接 使?即可:?如 Java 中的 Redisson, C++ 中的 redis-plus-plus. 当然, 有些??也会有??版本的分布式锁的实现。
?????????当然以上仅仅是例举了分布式锁的一些实现特性,实际中分布式锁需要考虑的问题复杂、繁多。此处我们不做过多讨论了。
① 什么时分布式锁?
② 分布式锁的一些特性:如何加\解锁? 设置过期时间、校验机制、原子性(lua脚本)、看门狗、Redlock算法
本篇到此结束,感谢你的阅读。
祝你好运,向阳而生~