如何规范网站使用,网络运维面试题,湖南企业竞价优化首选,凡科网登录电脑端#xff08;一#xff09;为什么要有分布式锁以及本质 在一个分布式的系统中#xff0c;会涉及到多个客户端访问同一个公共资源的问题#xff0c;这时候我们就需要通过锁来做互斥控制#xff0c;来避免类似于线程安全的问题 因为我们学过的sychronized只能对线程加锁…一为什么要有分布式锁以及本质 在一个分布式的系统中会涉及到多个客户端访问同一个公共资源的问题这时候我们就需要通过锁来做互斥控制来避免类似于线程安全的问题 因为我们学过的sychronized只能对线程加锁在分布式系统中无法对进程进行加锁此时我们就需要用分布式锁 那分布式锁的本质我们可以理解为一个公共服务器来记录加锁的状态那我们这里使用redis来作为这个公共服务器
二分布式锁的基本实现
1.基础实现 我们说分布式锁的本质是服务器来记录加锁状态那这个加锁的本质就是通过一个键值对的方式来标识锁的状态 就用我们常见的购票场景我们现在有多个服务器节点来提供购票需求那购票的流程先查询指定车的余票如果余票0就-1很明显这个操作不是原子的就会导致有其他服务器节点插到中间执行这就会导致超卖的情况这种情况在单机上我们可以通过对线程加锁的方式来处理但是加锁对于多进程来说是无能为力的 如果我们最终存储数据的服务器是mysql我们可以使用事务来解决但是如果不是我们还是需要之后的步骤 那我们这里想要加锁我们就需要引入一个公共服务器作为分布式锁的管理者 我们服务器节点会先访问redis在redis设置一个键值对比如key是车次 如果这个操作设置成功就视为有服务器节点对这个车次进行加锁了其他的服务器节点想要购票时就也需要写一个键值对但是我们会发现这个key已经存在了此时就需要进行阻塞等待等到我们加锁的这个服务器节点在进行完数据库的读写操作后就要把redis刚才的键值对给删除掉这个删除操作就相当于释放锁然后我们其他的服务器节点才可以再次购票进行加锁解锁操作 注我们redis本来就是key-value结构并且提供了setnx操作当我们key不存在的时候就设置成功存在就设置失败所以使用redis很合适
2.引入过期时间 当服务器1加锁后解锁前如果服务器1挂了就会导致我们这个解锁操作不能执行那么其他的服务器程序就一直无法获取到锁 那我们之前讲多线程的时候使用了finally来保证最后一定会解决那这个能不能在分布式锁中使用呢 是不可以的因为我们加锁不是在自己进程中加的而是在一个公共服务器中加的程序异常退出是不会给公共服务器上的锁解锁的 那我们如果挂了为了解决无法解锁的问题不如我们未雨绸缪我们在设置key的同时引入过期时间来保证这个key存在多久就自动销毁这个锁加锁多久后自动解锁 那我们可以使用redis中的set ex nx的方式在设置锁的同时设置过期时间 注意如果我们使用setnx 后使用expire因为是两个指令不是原子的即使使用事务也不能保证都执行正确就导致可能会出现无法正确释放锁的问题
3.引入校验id 对于redis中的数据我们其他服务器节点也是可以删除的上述情况下我们一个服务器对他加锁后另一个服务器也可以进行解锁操作虽然我们不会故意让另一个服务区程序去解锁但是我们还是要保证不能因为一些bug导致服务器2把key误删了 为了解决这个问题我们可以把我们的服务器程序的编号给放到value中因为我们上述说是写key然后校验key是否存在来判断是否加锁的这个value的值就可以任我们发挥那我们value放服务器编号然后我们想要解锁时先判断这个key对应的value是不是我们当前的服务器如果是就进行删除不是就不可以删除
那我们伪代码如下 我们发现这里的get和del不是原子的那就可能会出现错误 如果在多线程的情况下就会导致重复删除一个key那有人会有疑问重复删就删了呗那如果此时正好有一个set key在最后一个del之前执行呢这就会导致我们新设置的key被直接删除了 那这里的问题我们可以使用redis事务来解决也可以使用lua脚本
4.lua脚本 lua是redis的一个内嵌语言语法简单并且执行速度快且轻量并且redis官方文档说我们可以使用lua来实现redis的事务 因为redis执行lua脚本是相当于一个操作也就是原子的但是lua脚本中可以有很多操作
如果使用lua脚本那代码可以写为 5.引入watch dog 上述方案还有一个问题也就是我们过期时间的设置我们设置了key过期时间后可能会导致我们任务没执行完key就过期了或者当我们key过期时间很长就会导致其他服务器无法及时加锁那么针对这个问题我们就引入了一个watch dog本质上是加锁服务器上的一个单独线程来针对这个加锁时间进行“续约” 就比如我们先设置过期时间1s当还剩300ms我们任务没执行完我们这个watch dog线程就会把过期时间重新设置也就是续约过程这样就不用担心过期时间设置的过长或者过短了因为过期时间变成了动态的 而且当我们服务器挂了这个线程也就挂了过期时间就不会改变就可以正常的释放锁
6.引入redlock
我们上述都是在讨论服务器节点的问题那假如我们redis服务器挂了呢这时有人会说主从结构和哨兵可以帮我们解决啊我们一直会有主节点的虽然是这样但是会存在我们之前的主节点中有一些加锁操作没来得及同步数据给从节点导致数据丢失这样就相当于没有加锁其他服务器就可以进行加锁 那为了解决这种问题redis作者提出了redlock算法
也就是引入了一组redis节点每一组都是相同的主从结构并且数据也相同加锁的时候我们按照一定顺序写多个master节点写操作时要设定操作的超时时间当set key的操作超过超时时间没有成功就视为加锁失败 如果给某个节点加锁失败就尝试下一个节点当加锁成功的节点数超过总数一半就视为加锁成功 这个算法就是通过空间换取准确度
