１．抽奖/秒杀并发情况下库存为负数问题
场景：一个商品有库存，下单时先检查库存，如果>0，把库存-1然后下单，如果<=0，则不能下单，事务包含两条sql语句：
select quantity from products WHERE id=3;
update products set quantity = ($quantity-1) WHERE id=3;
在并发情况下，可能会把库存减为负数(两个进程同时select出来的都>0,然后都会执行update)，怎么办呢？
方法1：
（悲观锁）
InnoDB支持通过特定的语句进行显示加锁：
select...lock in share mode #共享锁
select...for udpate #排他锁
select quantity from products WHERE id=3 for update;
或
select quantity from products WHERE id=3 lock in share mode;
update products set quantity = ($quantity-1) WHERE id=3;
但是执行for update会产生一些其他的影响
1.select语句变慢
2.一些优化无法正常使用,例如索引覆盖扫描
3.很容易造成服务器的锁争用问题(死锁)
方法二：
把udpate语句写在前边，先把数量-1，之后select出库存如果>-1就commit,否则rollback。
update products set quantity = quantity-1 WHERE id=3;
select quantity from products WHERE id=3 for update;
上边的事务中先执行了update，所以id=3的行被加了行锁,只有commit/rollback是才会被释放（事务中锁是逐步获得的，但是都是commit时所释放的）。很好的解决了并发问题。
方法三：
update语句在更新的同时加上一个条件
$quantity = select quantity from products WHERE id=3;
update products set quantity = ($quantity-1) WHERE id=3 and queantity = $quantity;
这样虽然select语句没有加锁，但是因为mysql的事务隔离级别是可重复读，所以其他事务的修改不会影响到select的结果，当执行到update时，如果有其他事务锁住了这条记录，update会等待，等到其他事务释放锁，update会执行，但此时如果quantity的数量已经被修改，update的执行会返回影响行数为0。
原因：
比如先select出来的$quantity=3，然后执行update的条件为id=3 and quantity=3,执行更新返回影响函数为0，但再次执行select时发现id=3的记录quantity确实是3啊，怎么有这条记录却更新不了呢？这归功于“mysql的事物隔离级别和MVCC，当第一个select时 quantity=3，然后其他事务先于这个update执行了，导致update的条件并没有找到合适的记录，因为在可重复读级别中，update的读是“当前读”，读取的是最新的数据。而再次select时查到的quantity还是等于3，因为对于select的读是“快照读”，读取的是历史数据，这也是可重复读级别的特性”
方法四
（乐观锁）
使用version数据库版本号字段来控制.
update 时将version值加1，看select时的version和下一步update时的version是不是同一个版本号，以此来判断当前的数据是不是之前查询到的数量值，还是已被其它线程已经修改过后的数量值。
update t set surplus = 90 ,version = version+1 where id = x andversion = oldVersion ;
但是如果数据竞争激烈,则自动重试次数会急剧上升,需要注意。
方法五
把库存字段改为unsigned
这样可以保证库存不为负数，如果并发情况下被扣为负数的时候会报错，这个时候try catch然后返回库存不足就可以了
方法六
用redis的队列模式
把所有请求插入到redis的队列了，当库存达到阈值后停止插入，然后消费redis里的数据
方法七
利用redis的incrby特性来扣减库存
- 系统初始化的时候，将商品库存加载到Redis 缓存中保存
- 在秒杀的时候，先进行预减库存检测，从redis中，利用decr 减去对应商品的库存，如果库存小于0，说明此时 库存不足，则不需要访问数据库。直接抛出异常即可
