此文章只解决，针对库存变成负数进行浅显的分析并解决。对于高并发的问题不予考虑。自己的技术没有达到嘛！
先说下问题：
一般刚接触减少库存的问题都会这样写：
查询库存是否够用->变更库存数量->结束
这种情况是如何出现的呢？模拟一下：
（1）用户1查询id为1的商品的库存为1，刚查完还没有进行修改库存
（2）用户2查询id为1的商品的库存也为1（因为用户1还没有修改），也还没进行修改
（3）用户1进行修改库存，库存变成0
（4）用户2进行修改库存，库存变成-1
就是这个样子
解决的办法：
利用事务，锁。当一个链接进入到事务，那么在修改一条数据之后，只要还没有commit。那么其他人只能等候。
这里的锁的原理就不说了。因为涉及到的东西特别的多。有兴趣的可以去看
MySQL技术内幕:InnoDB存储引擎
这本书。
说下实际解决方案：
（1）用户1开启事务，并且查询库存为1
（2）用户2开启事务，并且查询库存也为1（这个锁只对update有效果，现在可以这么理解哈。因为说的太多，扯的就多了。可以自己看书了解这是为什么）
（3）用户1修改库存，库存为0（但是记住，你还没有提交事务）
（4）用户2修改库存，修改不了，因为在等待用户1提交库存，他才可以修改
（5）用户1，查询库存，库存为0，ok，提交事务
（6）用户2，等待结束，修改库存，库存为-1（但是记住，还没有提交事务，可以回滚哦）
（7）用户2，查询库存，库存为-1，NO，回滚
这里用户1，修改之后没有提交事务，当用户2修改的时候，处于等待状态
这里还有最重要的一点哈。你的表引擎必须是innodb的。myisam是不支持事务的。
好了，这篇文章主要是针对初级的，没有考虑高并发。以后会再写一篇针对高并发的解决方案。不过这个还是基础吧。
针对于高并发，主要是让数据库处理的请求少一些，把一些不必要的避之门外。
