我们知道数据库处理sql是一条条处理的，假设购买商品的流程是这样的：
sql1:查询商品库存
if(库存数量 > 0)
{
//生成订单...
sql2:库存-1
}
当没有并发时，上面的流程看起来是如此完美，假设同时两个人下单，而库存只有1个了，在sql1阶段两个人查询到的库存都是>0的，于是最终都执行了sql2，库存最后变为-1，超售了，要么补库存，要么等用户投诉吧。
解决这个问题比较好的方法是什么呢？
update table set n = n-x where n >= x不需要事务，直接获取affected row count来判断是否扣成功，后到的那一条因为n=0，affected row肯定为0
库存字段改成unsigned int。
这样的话不会<0，顶多就SQL执行出错。
也可以用memcached/redis来缓存结果，从缓存中查询。
1.MySQL数据库加锁,乐观锁 和 悲观锁
2.用队列,排队逐一去生成订单
用事务处理机制
数据表加锁也行(如果你用
InnoDB引擎就用行锁;如果你用MyISAM引擎就用表锁)
想问一下，并发量大的情况下，是怎么做的呢？
库存缓存一般都是 有的吧，如果有并发需求。 还有就是加锁，或者放到队列执行sql。
处理高并发一般来说都会用到Redis，使用Redis的list数据结构（高并发当然要异步队列咯）来存储请求过来的订单信息，然后启用redis的事务机制（见：http://redis.io/topics/transactions），加入指定key的list前，判断该list等长度是否超过redis中保存的指定商品库存值，如果超过则不操作，如果不超过，则进行插入，插入之后，再次判断该list的长度是否超过redis中保存的指定商品的库存值，如果超过则回滚，否则提交。
1.用事务保持操作原子性，
2.在修改库存的时候先用select...for update把数据锁好
有种很笨的方法，已楼主的假设为例：
sql1:查询商品库存 （假设查出的库存为10）
if(10 > 0)
{
//生成订单...
sql2: 10 - 1 （此时库存为9了）
//再校验库存
sql3: 查询商品库存 == 9 （如果此时有并发情况，那查出来的库存可能为8、7等，这时抛出异常，事务回滚，该笔订单无效。）
}