【JavaP6大纲】功能设计篇：库存超卖问题

库存超卖问题

针对秒杀建议选择下单扣库存的方式：首先查询redis缓存库存是否充足先扣库存再落订单数据，可以防止订单生成了没有库存的超卖问题扣库存的时候先扣数据库库存，再扣减redis库存，保证在同一个事务里，无论两者哪一个发生了异常都会回滚。有一个问题是可能redis扣成功了由于网络问题返回失败，事务回滚，导致数据库和缓存不一致，这样实际少卖了，可以放到下轮秒杀去。

库存超卖问题是有很多种技术解决方案的，比如悲观锁，分布式锁，乐观锁

悲观锁

采用排他锁（悲观锁）
当用户同时到达更新操作，同时到达的用户一个个执行
在当前这个update语句commit之前，其他用户等待执行

分布式锁

采用Redis的队列实现，用于抢购
先从MySQL读取库存数，放到Redis的队列中
用户直接操作队列，当队列为空时提醒售空
当抢购结束后可执行更新库存表操作

redis分布式锁还是zookeeper分布式锁？
redis分布式锁类似于自旋锁的方式需要自己不断尝试去获取锁，这个是比较耗性能的。zk获取不到锁的话则可以注册监听器，不需要不断尝试，这样的活性能开销较小；其次，redis锁有一个问题就是，如果获取到锁的客户端崩溃了或者没有正常释放锁则会导致只能等到过期时间完了才能获取到锁，而zk建立的由于是临时节点，客户端崩溃了或者挂了，临时节点会自动删除，此时会自动释放锁；最后，这个redis的实现方式如果采用RedLock算法的话较为复杂并且还存在争议