以座位预定业务为背景:
用户A查询座位S是否空闲,结果是空闲;
用户B查询座位S是否空闲,结果是空闲;
用户A预定座位S,将座位S状态设置为占用;
用户B预定座位S,将座位S状态设置为占用;
上述流程导致座位S被重复预定。
解决方案:
- 在业务层,使用队列或者分布式锁,来保证数据库层的并发安全,这种方式在业务量小时,有点大材小用;
- 使用悲观锁,第一个用户查询时,会触发锁行,或者锁表,其他用户查询时只能等待悲观锁在事务结束后释放才行,这会极大影响并发性能;
- 使用乐观锁,等用户最终要提交更新时,确保第一次查询的状态数据和更新时的状态数据一致,并且该操作必须是在一条update语句中完成,这是利用了update语句的原子操作性的特点;该方案在写操作很少,主要是读操作时,效果好;否则大部分update都失败,会导致用户体验极差;
悲观锁使用方式:
Begin transaction
Select * from tablename where xxx for update
... ...
Update tablename xxx
End transaction
乐观锁使用方式:
Begin transaction
Select * from tablename where xxx
保存条件值,此处假设为old_status = 0
... ...
Update tablename xxx where status = old_status
如果条件不成立,则更新失败。
End transaction
备注:乐观锁,在查到的文章里都说要使用version或者时间戳,但是我觉得本质还是为了保障你查询的那条记录,在你更新时,没有被其他事务修改过,因此根据实际业务需求,不一定必须要用version或时间戳,达到目的即可。