关于超卖程序问题分析-java

关于超卖程序问题分析

1.并发情况下，GET缓存 + 判断>0，成立，均执行扣减库存，导致超卖

2.加锁

以库存key，加锁，setNx，finally解锁

deleteKey

存在问题

1.误解锁（是不是也是因为加锁时间过短问题，释放锁时出现问题）

参考

REDIS distlock -- Redis中国用户组（CRUG）

举个例子：客户端A取得资源锁，但是紧接着被一个其他操作阻塞了，当客户端A运行完毕其他操作后要释放锁时，原来的锁早已超时并且被Redis自动释放，并且在这期间资源锁又被客户端B再次获取到。如果仅使用DEL命令将key删除，那么这种情况就会把客户端B的锁给删除掉。使用Lua脚本就不会存在这种情况，因为脚本仅会删除value等于客户端A的value的key（value相当于客户端的一个签名

2.加锁时间过短，业务未执行完，锁提前释放。超卖

解决方案：看门狗

-------

1.单机未加锁

synchronized 关键字 并发，【不见不散】，抢不到，海枯石烂，一直等，导致线程积压

ReetrantLock 类，tryLock，尝试获取锁，【过时不候】，等待一定时间，放弃

tryLock - lock - unLock

2.分布式架构

NG - Getway - 微服务

分布式锁注意

1.加锁：指定value 

2.加过期时间：避免服务宕机，无法释放锁；且加锁+过期时间，保证原子性，SETNX

2.解锁：在finally中执行（异常释放），判断value，且必须要用lua脚本，保证原子性。

4.rediscluster集群

master slave；master -> slave，同步问题。master宕机，未同步到slave，slave升级master，客户端无法取到值。导致不同节点数据不一致。

CAP问题

redis AP ，可用性

ZK cp ，一致性

方案：

redlock 落地方案 redisson。

自动延时机制

只要客户端1一旦加锁成功，就会启动一个watch dog看门狗，他是一个后台线程，会每隔10秒检查一下，如果客户端1还持有锁key，那么就会不断的延长锁key的生存时间。

5.redisson

参考文档

Redis：Redisson分布式锁的使用（推荐使用）_穿城大饼的博客-CSDN博客

源码

Redis客户端连接工具资料 -- Redis中文网 -- Redis中国用户组（CRUG）