怎么预防数据库超售？

        第一种办法技术上最稳妥，但是业务上不可行。那就是设置事务的隔离级别为Serializable。这个事务隔离级别非常严格，因为多个事务并发执行，对同一条记录修改，就会出现超售现象。所以干脆，咱们就禁止事务的并发执行。Serializable就是让数据库串行执行事务。一个事务执行完，才能执行下一个事务。这种办法确实解决了超售的问题。但是，SQL语句对数据的修改，最终都是要反应到磁盘上的。磁盘的IO速度你也是知道的，比内存和CPU慢多了。所以说，串行化执行事务，一个事务执行的时间就不短。你让后面排队的事务等到什么时候？

        第二种方法是给数据表设置乐观锁。我们在数据表上面添加一个乐观锁字段，数据类型是整数的，用来记录数据更新的版本号。这个跟SVN机制很像。乐观锁是一种逻辑锁，它是通过版本号来判定有没有更新冲突出现。比如说，现在A商品的乐观锁版本号是0，现在有事务A来抢购商品了。事务A记录下版本号是0。等到执行修改库存的时候，就把乐观锁的版本号设置成1。但是事务A在执行的过程中，还没来得及执行UPDATE语句修改库存。此时事务B进来了，它执行的很快，直接把库存修改成99，然后把版本号变成了1。这时候，事务A开始执行UPDATE语句，但是发现乐观锁的版本号变成了1。这说明，肯定有人抢在事务A之前，更改了库存，所以事务A就不能更新，否则就会出现超售现象。

        第三种方法 Redis的事务机制避免超售。Redis的事务跟MySQL的事务完全不是一回事儿。Redis的事务就是个批处理机制。底层的原理和乐观锁类似，只不过把乐观锁拿到内存中来实现。MySQL乐观锁会把事务放在数据库解决，给数据库很大的压力。下面详细说明一下Redis的事务机制：

        Redis是单线程的。可能会交叉执行不同客户端的指令。批处理方式会让Redis短时间内只处理一个客户端的指令。避免交叉式的并发指令产生。

        比如说现在客户端A，在修改数据之前，首先要观察要修改的数据，相当于记下了数据的版本号（不用咱们手动添加版本号字段）。然后我们可以开启事务机制。于是所有的命令都不会立即发送给Redis，而是先缓存到客户端本地。等我们提交事务的时候，一次性 把这个命令发送给Redis。Redis分析版本号之后，发现没问题。这时候就会执行这些批处理命令，而且在执行过程中不允许打断，不会处理其他客户端的命令。这样就不会出现超售现象。