乐观锁,大多是基于数据版本(Version)记录机制实现。
数据版本即为数据
增加一个版本标识,在基于
数据库表的版本
解决方案中,一般是通过为
数据库表
增加一个“version”字段来实现。
读取出数据时,将此版本号一同读出,之后更新时,对此版本号加一。此时,将提交数据的版本数据与
数据库表对应记录的当前版本信息进行比对,如果提交的数据版本号大于
数据库表当前版本号,则予以更新,否则认为是过期数据。
对于上面
修改用户帐户信息的例子而言,假设
数据库中帐户信息表中有一个version字段,当前值为1;而当前帐户余额字段(balance)为$100。
1操作员A此时将其读出(version=1),并从其帐户余额中扣除$50($100-$50)。
2在操作员A操作的过程中,操作员B也读入此
用户信息(version=1),并从其帐户余额中扣除$20($100-$20)。
3操作员A完成了
修改工作,将数据版本号加一(version=2),连同帐户扣除后余额(balance=$50),提交至
数据库更新,此时由于提交数据版本大于
数据库记录当前版本,数据被更新,
数据库记录version更新为2。
4操作员B完成了操作,也将版本号加一(version=2)试图向
数据库提交数据(balance=$80),但此时比对
数据库记录版本时发现,操作员B提交的数据版本号为2,
数据库记录当前版本也为2,不满足“提交版本必须大于记录当前版本才能执行更新“的乐观锁策略,因此,操作员B的提交被驳回。
这样,就避免了操作员B用基于version=1的旧数据
修改的结果覆盖操作员A的操作结果的可能。
乐观锁机制避免了长事务中的
数据库加锁开销,大大提升了大并发量下的系统整体
性能表现。