数据库锁之乐观锁

一、乐观锁的介绍

乐观锁是相对悲观锁而言，也是为了避免数据库幻读、业务处理时间过长等原因引起数据处理错误的一种机制，但乐观锁不会刻意使用数据库本身的锁机制，而是依据数据本身来保证数据的正确性。

乐观锁的机制：对每条数据库加上版本号或时间撮，在每次对数据进行操作(尤其是修改操作)时，总会带上版本号获取数据同时更改后修改版本号。

二、乐观锁的代码示例

2.1 创建一张表

create table em_oplock

(

id VARCHAR(100) not null,

value VARCHAR(100),

version int(10),

PRIMARY key(id)

) ENGINE=INNODB DEFAULT CHARSET=utf8;

2.2 插入一条数据

INSERT into em_oplock values('1','1',1);

2.3 修改数据

update em_oplock set value='2',version=version+1 where id = 1 and version = 1;

三、乐观锁的业务使用示例

事务1

事务2

说明：

当两个用户同时操作ID为1的数据或一个用户未处理完另一个用户也对此数据操作时，两个用户获取数据做了一系列的业务处理后都认为自己的数据判断是正确的，于是都对同一条数据进行修改提交。如果我们不做版本控制的话，后处理的用户将覆盖前面用户的数据。如果我们加上版本控制的话，当用户1处理成功后，用户2将一条数据都不会处理。

四、悲观锁的业务使用示例

事务1：成功锁定数据

事务2：等待锁的释放

事务1：操作锁定数据并提交，同时释放锁定数据

事务2：获取数据锁（最新数据）

说明：

为了对数据处理的正确性，在操作数据前先对数据进行锁定(for update)。利用数据库本身的排它锁机制，保证了数据只能一个用户一个用户的处理。

五、乐观锁与悲观锁的比较

5.1 乐观锁需要增加额外的字段来记录版本号，增加了数据库设计复杂度。(乐观锁的劣势)

5.2 乐观锁需要每个修改的地方同时更新版本号，增加了开发的成本。(乐观锁的劣势)

5.3 当并发量大或业务时间处理比较长时，就会造成数据库锁长时间等待，限制并发量和快速消耗数据库资源。(悲观锁的劣势)

5.4 悲观锁操作时，需要对数据库的锁机制有一定程度的理解才行。否则，容易造成表锁或死锁。(悲观锁的劣势)

六、乐观锁与悲观锁的选择

不论是悲观锁还是乐观锁，都是为实际业务服务的，都是为了保证数据的正确性。选择乐观锁还是悲观锁需要根据具体的业务场景、数据库设计、开发成本等因素进行权衡。如果此业务涉及的面比较多、开发人员比较多等，建议用悲观锁。如果此业务比较单一或数据库操作的地方比较少、并发量要求很高等情况下，建议用乐观锁。

如果我们把业务设计得更合理一点，数据为设计更好一点，也许不需要这么麻烦！