数据库乐观锁

乐观锁

乐观锁(Optimistic Lock),顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在提交更新的时候会判断一下在此期间别人有没有去更新这个数据。乐观锁适用于读多写少的应用场景,这样可以提高吞吐量。

乐观锁:假设不会发生并发冲突,只在提交操作时检查是否违反数据完整性。

乐观锁一般来说有以下2种方式:

  1. 使用数据版本(Version)记录机制实现,这是乐观锁最常用的一种实现方式。何谓数据版本?即为数据增加一个版本标识,一般是通过为数据库表增加一个数字类型的 “version” 字段来实现。当读取数据时,将version字段的值一同读出,数据每更新一次,对此version值加一。当我们提交更新的时候,判断数据库表对应记录的当前版本信息与第一次取出来的version值进行比对,如果数据库表当前版本号与第一次取出来的version值相等,则予以更新,否则认为是过期数据。
  2. 使用时间戳(timestamp)。乐观锁定的第二种实现方式和第一种差不多,同样是在需要乐观锁控制的table中增加一个字段,名称无所谓,字段类型使用时间戳(timestamp), 和上面的version类似,也是在更新提交的时候检查当前数据库中数据的时间戳和自己更新前取到的时间戳进行对比,如果一致则OK,否则就是版本冲突。
### 数据库乐观锁的最佳应用场景 #### 场景一:低冲突频率的数据更新 当应用程序中的数据更新操作较少发生冲突时,采用乐观锁能显著提升系统性能。在这种情况下,多个客户端可以并行读取同一份数据而不必等待对方释放锁资源,在提交更前才检查是否有其他事务已对该记录进行了修。 对于电商网站的商品库存管理模块而言,商品详情页面展示给用户的只是当前时刻的一个快照视图;只有真正下单付款成功才会触发实际的数量扣减动作。因此大部分时间内浏览者之间不存在竞争关系,适合运用乐观控制策略来优化用户体验[^1]。 ```sql UPDATE products SET stock = stock - 1, version = version + 1 WHERE id = ? AND version = ? ``` 上述SQL语句展示了如何利用版本号字段实现简单的乐观锁定逻辑。如果两个并发请求尝试同时购买同一件商品,则只有一个会成功执行更新命令,另一个因条件不满足而失败返回错误提示信息让用户重试即可。 #### 场景二:高吞吐量环境下的高效协作 在某些业务流程里可能涉及到大量短周期的任务处理单元相互独立运作却又共享部分公共资源的情形下——例如金融交易清算平台上的订单匹配过程或是社交网络服务里的点赞互动功能——此时引入悲观型互斥机制往往会造成不必要的延迟甚至死锁现象的发生。相反地借助于非阻塞性质较强的乐观点同步方式则有助于维持较高的整体响应速度和服务质量水平。 考虑在线票务预订系统中座位分配环节的工作原理:每当有新顾客发起购票申请时都会先获取最新可用座席列供其挑选确认心仪位置后再正式预定下来。由于整个过程中间存在较长的人机交互间隔期间内很难预估具体哪一刻会出现抢购高潮期故不宜采取强占有式的保护措施而是应该允许后续到来的竞争者继续查看剩余选项直至最后一刻才决定是否占用该资源从而最大化利用有限的空间容量创造更多价值[^3]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值