Mysql-乐观锁-实现

乐观锁介绍：

        乐观锁（ Optimistic Locking ） 相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。而乐观锁机制在一定程度上解决了这个问题。乐观锁，大多是基于数据版本（ Version ）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号等于数据库表当前版本号，则予以更新，否则认为是过期数据

乐观锁的实现：

使用版本控制字段，再利用行锁的特性实现乐观锁，如下

有一张订单表order，有字段id、order_no、 price,  为实现乐观锁控制，添加version字段，默认值为0

order

id 1

order_no 123456

price 5

version 0

假设两个人同时进来修改该条数据，操作为：

1. 先查询该数据   select * from order where id = 1

2. 修改该条数据  update order set price = 1 where id = 1

如果两个人同时查询到该条数据price = 5， 可以执行update操作， 但任意一方还没执行update操作，那么最后双方都执行update，导致数据被修改两次，产生脏数据 !

使用version字段控制版本后：

1. 两人先查询该数据 select * from order where id = 1

此时两人查询到的数据一样，id = 1, price = 5, order_no = 123456, version = 0

2. 两人都发现该条数据price = 5， 符合update条件，第一人执行update（因为mysql行锁的特性，两人不可能同时修改一条数据，所以update同一条数据的时候，是有先后顺序的，只有在第一个执行完update，才能释放行锁，第二个继续进行update）: 

update order set price = 1, version = version + 1 where id = 1 and version = 0

执行完成后，version字段值将变成1, 第二人执行update:

update order set price = 1, version = version + 1 where id = 1 and version = 0

此时的version的值已经被修改为1，所以第二人修改失败，实现乐观锁控制。

死锁的处理：

数据库使用乐观锁导致产生死锁：

假设在两个事务中有以上两个操作，同时修改order表中两条数据

事务A在执行完第一条update的时候，刚好事务B也执行完第一条update

此时，事务A中order表中的id = 1的行被锁住， 事务B中order表中id = 2的行被锁住，两个事务继续往下执行

事务A中第二条update执行需要order表中id = 2的行数据，而事务B中第二条update执行需要id = 1的行数据， 两条update往下执行的条件都需要对方事务中已经被锁住的行，于是陷入无限等待，形成死锁。

解决死锁的产生：

指定锁的执行顺序，比如把以上两事务稍作修改

事务A执行第一条update时，id = 2 的行被锁住，此时，事务B想修改id = 2的行，只能等待事务A执行完成，当事务A执行完成时，事务B再执行， 这样就不会产生死锁了。