悲观锁与乐观锁是人们定义出来的概念,你可以理解为一种思想,是处理并发资源的常用手段。其与mysql中提供的锁机制(表锁,行锁,排他锁,共享锁)并不同,后者可以成为前者的实现手段。
悲观锁
顾名思义,就是对于数据的处理持悲观态度,总认为会发生并发冲突,获取和修改数据时,别人会修改数据。所以在整个数据处理过程中,需要将数据锁定。悲观锁的实现,通常依靠数据库提供的锁机制实现,比如mysql的排他锁,for update来实现悲观锁。
例子:商品秒杀过程中,库存数量的减少$num,避免出现超卖的情况。
CREATE TABLE tb_goods_stock
(
id
bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT 'ID',
goods_id
bigint(20) unsigned DEFAULT '0' COMMENT '商品ID',
nums
int(11) unsigned DEFAULT '0' COMMENT '商品库存数量',
create_time
datetime DEFAULT NULL COMMENT '创建时间',
modify_time
datetime DEFAULT NULL COMMENT '更新时间',
PRIMARY KEY (id
),
UNIQUE KEY goods_id
(goods_id
)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='商品库存表';
将商品库存数量nums字段类型设为unsigned,保证在数据库层面不会发生负数的情况。
注意,使用悲观锁,需要关闭mysql的自动提交功能,将 set autocommit = 0;
注意,mysql中的行级锁是基于索引的,如果sql没有走索引,那将使用表级锁把整张表锁住。
开启事务,查询要卖的商品,并对该记录加锁。
begin;
select nums from tb_goods_stock where goods_id = {$goods_id} for update;
判断商品数量是否大于购买数量。如果不满足,就回滚事务。
如果满足条件,生成订单,减少库存,并提交事务。
insert into ----
update tb_goods_stock set nums = nums - {$num} where goods_id = {$goods_id} and nums >= {$num};
commit;
悲观锁在并发控制上采取的是先上锁然后再处理数据的保守策略,虽然保证了数据处理的独占性,但也降低了效率,尤其是for update查询的时候会锁定所有扫描的行(该列信息上没有索引,则锁定全表),这种情况在高并发情况下绝对是不能接受的。
乐观锁
乐观锁相对悲观锁而言,就是对数据的处理持乐观态度,它认为数据一般情况下不会造成冲突,所以在数据进行提交更新的时候,才会正式对数据的冲突与否进行检测,一般是利用版本号来操作。如果发现冲突了,则返回错误信息,让用户决定如何去做。接下来我们看一下乐观锁在数据表和缓存中的实现。
CREATE TABLE tb_goods_stock
(
id
bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT 'ID',
goods_id
bigint(20) unsigned DEFAULT '0' COMMENT '商品ID',
nums
int(11) unsigned DEFAULT '0' COMMENT '商品库存数量',
create_time
datetime DEFAULT NULL COMMENT '创建时间',
modify_time
datetime DEFAULT NULL COMMENT '更新时间',
version
bigint(20) unsigned DEFAULT '0' COMMENT '版本号',
PRIMARY KEY (id
),
UNIQUE KEY goods_id
(goods_id
)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8mb4 COMMENT='商品库存表';
进行如下操作
begin;
1.判断库存是否够用,但是这里只是为了看是不是有库存,如果没有将会尽快返回错误,但是不决定最终是否成功
select nums, version from tb_goods_stock where goods_id = {$goods_id};
2.生成订单
insert into ----
3.如果满足条件,则减少库存。(更新时判断当前version与第1步中获取的version是否相同)
update tb_goods_stock set nums = nums - {$num}, version = version + 1 where goods_id = {$goods_id} and version = {$version} and nums >= {$num};
4.判断更新操作是否成功执行,如果成功,则提交,否则就回滚。
乐观锁适用于读多的应用场景。但是对于版本号这种情况,如果并发量起来了,将会经常发生冲突,上层应用不断的让用户进行重新操作,这反而降低了性能,对于库存的情况还有另一种方案来解决
begin;
select (inventory) from items where id=100;
1.判断库存是否够用,但是这里只是为了看是不是有库存,如果没有将会尽快返回错误,但是不决定最终是否成功
2.如果上面判断库存还有,生成订单
insert into ----
3.如果满足条件,则减少库存。(更新时判断库存是否大于当前库存,不在加入版本号)
update tb_goods_stock set nums = nums - {$num} where goods_id = {$goods_id} and nums >= {$num};
4.判断更新操作是否成功执行,如果成功,则提交,否则就回滚。
这种情况下就基本解决的并发时候的问题。
注意:在更新数据的时候不要用预先计算出库存再更新数值的方式,一定要把计算和更新写在一条语句中变成原子操作。