目录
前言:
分布式系统买票示例
引入redis做分布式锁
引入过期时间
引入校验id
引入lua脚本
过期时间续约问题
redlock算法
小结:
前言:
在分布式系统中,涉及多个主机访问同一块资源,此时就需要锁来做互斥控制,避免出现类似线程安全问题。而Java中的synchronized只是对当前进程中的线程有效,多个主机实际上是多个进程,那么它就无能为力了,此时就需要分布式锁。
分布式系统买票示例
客户端访问买票服务器进行买票操作,当买到票之后数据库余票执行减1操作。
客户端1先执行查询余票操作,发现余票还有一张,买票成功后服务器操作数据库执行减1操作。如果此时客户端1还没有执行数据库减1操作,客户端2执行了查询余票操作,发现余票也是一张,那么也进行数据库减1操作,那么此时客户端1和客户端2都会买到票。把一张票卖给了两个人,显然这是不合理的。
引入redis做分布式锁
引入分布式锁,所谓分布式锁实际上就是一个/一组单独的服务器程序,给其他服务提供 “加锁” 服务。redis是一种典型的实现分布式锁的方案,但不是唯一一种。
为了解决上述超卖问题,买票服务器在进行买票的时候,就需要先加锁。
加锁实际上就是在redis上设置一个特殊的键值对,完成上述买票操作再删除这个键值对。(此时认为这个键值对就是分布式锁)
其他服务器在买票的时候,也去redis尝试设置这样的键值对,如果发现键值对已经存在,就认为“加锁失败”,此时该进程是放弃还是阻塞就看具体的实现策略了。
这样就可以保证第一个服务器执行查询-更新的过程中,第二个服务器不会执行查询操作,也就解决了上述超卖问题。
注意:
上述买票的场景也可以使用MySQL的事务解决,批量执行查询-更新操作。但是分布式系统中数据库不一定是MySQL,也可能是其他数据库没有事务,因此使用redis作为分布式锁是比较好的解决方案。
引入过期时间
redis中使用 set nx 命令可以实现加锁效果,解锁使用 del 命令来完成。
如果某个服务器 set nx 成功了,还没有执行 del 命令就挂了,此时redis上的锁就无法删除,其他服务器就无法获取到锁。
解决方案:
可以在set key 的时候设置过期时间,一旦时间到锁自动就释放了。redis中可以使用 set ex nx命令完成。此时这个过期时间范围设置就显得尤为重要了,后面会有解释(过期时间续约问题)。
注意:
务必使用 set ex nx 命令一次性执行加锁和设置过期时间操作。如果使用set nx 设置锁,然后使用 expire 设置过期时间,就可能出现这两个命令一个成功一个失败,就算使用redis事务只能保证两条命令一块执行,但不能保证其正确性。相比之下一条命令直接操作就比较稳妥。
引入校验id
是否会出现服务器1执行了加锁操作,被其他服务器删除的情况呢?
这种情况有可能出现,代码总会有bug,需要提前去防止。
解决方案:
给服务器编号,每个服务器都有自己的唯一标识。进行加锁的时候,设置键值对.key对应要对哪个资源加锁(比如车次),value就可以存储服务器编号,标识出这个锁是哪个服务器加的。
解锁的时候就可以进行校验,先查询这个锁的服务器编号,和自己服务器编号进行对比。如果一致则执行解锁操作,否则就失败。服务器这边需要执行校验逻辑,此时就可以有效避免误解锁。
引入lua脚本
一个服务器内部也可能是多线程的,就有可能存在两个线程执行上述判断然后解锁操作。由于不是原子的,就有可能出现问题。
服务器1的线程A和线程B都执行解锁操作,如果线程A拿到锁判断完后,还没有执行DEL操作,此时线程B也拿到锁判断也会成功,那么就会执行两次DEL操作。
如果在线程A执行DEL之后,线程B执行DEL之前,服务器2的线程C在redis中进行加锁操作(此时由于线程A已经执行了DEL操作,因此可以加锁成功)。由于线程B已经校验完成,那么执行DEL就会删除掉服务器2加的锁。该问题就是因为GET和DEL操作不是原子的,就会出现问题。
解决上述问题,可以使用redis事务,保证GET和DEL的原子性,在执行期间不会有插队情况出现。但是一般不会这样做,引入lua脚本是更加有效的解决方案。
lua是一门编程语言,作为redis内嵌脚本,lua语言特别轻量,实现一个lua的解释器消耗系统资源非常小。
可以使用lua编写一些逻辑,把这个脚本上传到服务器上,然后客户端就可以控制redis执行这些脚本了。redis执行lua脚本的时候,是原子的,相当于执行一条命令一样。(redis官方文档中提出lua属于是redis事务的替代方案)。
过期时间续约问题
在加锁的时候key需要设置过期时间,那么这个时间设置多少合适呢?
如果设置短,那么有可能在业务逻辑还没执行完,锁就被释放了。
如果设置长,那么锁释放就会不及时。
动态续约:
初始情况下设置一个时间比较短的过期时间(灵活进行调整),如果发现时间快到的时候,业务逻辑还没执行完,那就在续上一些过期时间(无限续约)。直到业务逻辑执行完成,锁也可以在较短时间内被释放。
如果服务器中途挂了,那也没有负责续约的线程了,此时锁也可以在较短时间内被释放。
动态续约往往需要服务器这边一个专门的线程负责,把这个线程就叫做看门狗(watch dog)。
redlock算法
使用redis作为分布式锁,那么就需要保证redis的高可用。
使用redis哨兵机制,当主节点挂了可以投票选举从节点作为主节点。但是如果在主节点加锁后还没来得及同步给从节点,主节点就宕机了。此时哨兵选举的从节点也就不存在该锁了。
作为分布式系统,就需要随时考虑某个节点挂了,不会影响大局。
redlock算法核心思想就是:冗余
此处加锁会按照一定顺序,对这些redis主节点都进行加锁。如果某个节点宕机了,没关系继续给下一个redis主节点加锁。如果加锁成功节点个数超过总个数一半,就视为加锁成功。同理,解锁需要把上述节点都执行解锁操作。这里就不会因为某个节点挂了,而导致加不上锁的情况。
小结:
这里实际上实现了互斥锁,还可以使用redis做读写锁,可重入锁,公平锁等等。