资料内容：
Redis分布式锁存在的问题
在购票软件的情境中，当仅剩一张或几张票时，众多用户同时尝试购买。在不考虑任何外部干扰的情况下，
逻辑上，系统应首先检查是否还有余票。如果仍有余票，用户可以顺利购买并导致库存相应减少；如果没有
余票，系统会提示用户票数不足，购买失败。伪代码如下：
void buyTicket() {
int stockNum = byTicketMapper.selectStockNum();
if(stockNum>0){
//TODO 买票流程....
byTicketMapper.reduceStock(); // 扣减库存
}else{
log.info("=====>票卖完了<====");
}
}
这段代码在逻辑上没有问题，但是在并发场景下，可能会存在一个严重的问题。当剩余票数为1时，有A,B两
个用户同时点击了购买按钮，A用户通过了库存大于0的校验并开始执行购票逻辑，但是由于一些原因造成A
用户的购票线程有短暂的阻塞。而在这个阻塞的过程中，用户B发起了购买请求，并且也通过了库存大于0的
校验，直到整个购买流程执行完成并且扣减了库存。那么这个时候剩余库存刚好为0，不会再有用户发起购
买请求，这时用户A的购买请求阻塞被唤醒，因为在此之前已经校验过库存大于0，所以执行完购买流程后，
库存还会被扣减一次。那么此时的库存为-1，这就是常听到的超卖问题。
