专业网站设计制作费用,企业网站建设好的案例,外网资源,HTML网站页面建设在分布式系统下#xff0c;涉及到多个节点访问同一个公共资源的情况#xff0c;此时需要通过 锁 进行互斥控制#xff1a;避免出现 线程安全问题。
1.分布式锁的基本实现
超卖问题#xff1a; 解决:
采用redis实现分布式锁
可用采取#xff1a;在购票的时候#xff0…在分布式系统下涉及到多个节点访问同一个公共资源的情况此时需要通过 锁 进行互斥控制避免出现 线程安全问题。
1.分布式锁的基本实现
超卖问题 解决:
采用redis实现分布式锁
可用采取在购票的时候操作过程中需要先加锁。在redis上设置一个key - value完成上述买票操作再把key - value 删掉。如果发现key - value 存在就加锁失败无法进行购票
上述可用保证第一个服务器执行查询 - 更新过程中第二个服务器不会执行 查询操作
具体实现
redis中的setnx命令不存在就设置进去当前key值存在就失败解锁使用del
考虑一下特殊情况
某个服务器加锁成功后在执行后续逻辑的过程中程序崩溃了没有执行到解锁操作
不可以采取finally这种做法只是针对进程内的锁有用针对分布式锁无效比如说服务器直接掉电进程异常终止后面的del逻辑都走不到~
还可以使用过期时间来实现~
给set的key设置一个过期时间时间到了key自动被删去了。
可以使用 set ex nx
异常情况
这个时候还有一个问题服务器1给redis上锁服务器2给解锁了会引起超卖问题
为了解决上述问题就需要加入校验机制
1、给服务器编号每个服务器有自己的身份标识
2、进行加锁的时候设置key-value。key对应着要针对哪一个资源进行加锁~value就可以存储刚才服务器的编号~~这样可以表示出这个锁是哪一个服务器加上的。
因此后续解锁的时候就可以进行校验了。
1、解锁的时候先查询一下这个锁对应的服务器编号然后判定一下这个编号 是否就是 当前执行的解锁的服务器编号。
2、如果是 才去执行del如果不是则失败 问题解锁时查询判定和del是非原子操作
一个服务器内部这是俩个行为会出现线程安全问题可以使用lua脚本实现原子性 但上述还有问题设置过期时间后仍然存在一定的可能性任务没执行完key先过期了导致锁提前失效。也就是过期时间的续约问题 这样负责动态续约 专门独立出来的 线程 叫 看门狗
高可用
如果使用redis作为分布式锁还需要考虑redis挂了的情况因此要想保证高可用需要一套预案去保证高可用。
搞几个哨兵节点 redlock算法
简而言之冗余 具体展现为
