Redis实现高并发下的抢购

抢购、秒杀是如今很常见的一个应用场景，主要需要解决的问题有两个：
1 高并发对数据库产生的压力
2 竞争状态下如何解决库存的正确减少（"超卖"问题）
对于第一个问题，已经很容易想到用缓存来处理抢购，避免直接操作数据库，例如使用Redis。
重点在于第二个问题
常规写法：
查询出对应商品的库存，看是否大于0，然后执行生成订单等操作，但是在判断库存是否大于0处，如果在高并发下就会有问题，导致库存量出现负数

优化方案1：将库存字段number字段设为unsigned，当库存为0时，因为字段不能为负数，将会返回false。

优化方案2：使用MySQL的事务，锁住操作的行
悲观锁：一次只允许一个人操作数据库或文件，其他人等待执行，但存在以下不足：
（1）高并发下，用户等待时间长
（2）请求时间长，这些请求会占用内存（服务器资源），导致网站直接崩溃
悲观锁：都可以请求同一个数据，认为数据是不会发生冲突的，但在真正要修改的时候，会检查数据是否冲突，会判断版本标识，如果版本不一样，则不执行操作，回滚

优化方案3：使用非阻塞的文件排他锁

优化方案4：使用redis队列，因为pop操作是原子的，即使有很多用户同时到达，也是依次执行，推荐使用（mysql事务在高并发下性能下降很厉害，文件锁的方式也是）

redis为什么比mysql执行的快
因为redis属于内存型、菲关系型数据库，key-value结构