wordpress调用图片上传优化软件

在分布式系统下，涉及到多个节点访问同一个公共资源的情况，此时需要通过 锁 进行互斥控制：避免出现 线程安全问题。

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算法

简而言之：冗余

 具体展现为：