关于超卖程序问题分析
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）
