乐观锁 -业务判断 解决高并发问题

     在解决高并发问题时，若是是分布式系统显然咱们只可以使用数据库端加锁机制来解决这个问题，可是这种同步机制或者数据库物理锁机制会牺牲一部分的性能，因此经常以另一种方式来解决这个问题 就是乐观锁模式

　　银行两操做员同时操做同一帐户就是典型的乐观锁模式。
      好比A、B操做员同时读取一余额为1000元的帐户，A操做员为该帐户增长100元，B操做员同时为该帐户扣除50元，A先提交，B后提交。最后实际帐户余额为1000-50=950元，但本该为1000+100-50=1050。这就是典型的并发问题。

      乐观锁机制在必定程度上解决了这个问题。乐观锁，大可能是基于数据版本(Version)记录机制实现。何谓数据版本？即为数据增长一个版本标识，在基于数据库表的版本解决方案中，通常是经过为数据库表增长一个 “version” 字段来实现。

　　读取出数据时，将此版本号一同读出，以后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，若是提交的数据版本号大于数据库表当前版本号，则予以更新，不然认为是过时数据。

　　对于上面修改用户账户信息的例子而言，假设数据库中账户信息表中有一个version字段，当前值为1；而当前账户余额字段(balance)为1000元。假设操做员A先更新完，操做员B后更新。
a、操做员A此时将其读出(version=1)，并从其账户余额中增长100(1000+100=1100)。
b、在操做员A操做的过程当中，操做员B也读入此用户信息(version=1)，并从其账户余额中扣除50(1000-50=950)。
c、操做员A完成了修改工做，将数据版本号加一(version=2)，连同账户增长后余额(balance=1100)，提交至数据库更新，此时因为提交数据版本大于数据库记录当前版本，数据被更新，数据库记录version更新为2。
d、操做员B完成了操做，也将版本号加一(version=2)试图向数据库提交数据(balance=950)，但此时比对数据库记录版本时发现，操做员B提交的数据版本号为2，数据库记录当前版本也为2，不知足 “提交版本必须大于记录当前版本才能执行更新 “的乐观锁策略，所以，操做员B的提交被驳回。
这样，就避免了操做员B用基于version=1的旧数据修改的结果覆盖操做员A的操做结果的可能。

操做员A操做以下：

select id, balance, version from account where id="1"; 
查询结果：id=1, balance=1000, version=1

update account 
set balance=balance+100, version=version+1 
where id="1" and version=1

select id, balance, version from account where id="1"; 
查询结果：id=1, balance=1100, version=2

 

操做员B操做以下：

select id, balance, version from account where id="1"; 
查询结果：id=1, balance=1000, version=1

#操做员A已修改为功，实际account.balance=1100、account.version=2，操做员B也将版本号加一(version=2)试图向数据库提交数据(balance=950)，但此时比对数据库记录版本时发现，操做员B提交的数据版本号为2，数据库记录当前版本也为2，不知足 “提交版本必须大于记录当前版本才能执行更新 “的乐观锁策略，所以，操做员B的提交被驳回。
update account 
set balance=balance-50, version=version+1 
where id="1" and version=1 

select id, balance, version from account where id="1"; 
查询结果：id=1, balance=1100, version=2

 

　　Hibernate、JPA等ORM框架或者实现，是使用版本号，再判断UPDATE后返回的数值