数据库高并发下乐观锁的原理
来源:互联网 发布:linux bluez 编辑:程序博客网 时间:2024/04/30 01:43
在高并发下,经常需要处理SELECT之后,在业务层处理逻辑,再执行UPDATE的情况。
若两个连接并发查询同一条数据,然后在执行一些逻辑判断或业务操作后,执行UPDATE,可能出现与预期不相符的结果。
在不使用悲观锁与复杂SQL的前提下,可以使用乐观锁处理该问题,同时兼顾性能。
场景模拟:
假设一张表两个字段,一个id,一个use_count。
表里存了100个id,每个id对应自己的use_count。
当id每使用一次,use_count要加1。当use_count大于1000时,这个id就不能在被使用了(换句话说 无法从数据库中查出)。
在高并发情况下,会遇到一种问题:假设数据表中有一条记录为:id=123456, use_count=999
A与B两个连接并发查询这个id=123456,都执行下列SQL:
SELECT
*
FROM
table
WHERE
id=123456
and
use_count < 1000;
A先执行,得到id=123456的use_count是999,之后在程序里做了一些逻辑判断或业务操作后执行SQL:
UPDATE
table
SET
use_count + 1
WHERE
id=123456;
在A做判断且没有update之前,B也执行了查询SQL,发现use_count是999,之后它也会执行SQL:
UPDATE
table
SET
use_count + 1
WHERE
id=123456;
但是,事实上B不应该取得这个id,因为A已经是第1000个使用者。
处理步骤如下:
1、添加第3个字段version,int类型,default值为0。version值每次update时作加1处理。
ALTER
TABLE
table
ADD
COLUMN
version
INT
DEFAULT
'0'
NOT
NULL
AFTER
use_count;
2、SELECT时同时获取version值(例如为3)。
SELECT
use_count, version
FROM
table
WHERE
id=123456
AND
use_count < 1000;
3、UPDATE时检查version值是否为第2步获取到的值。
UPDATE
table
SET
version=4, use_count=use_count+1
WHERE
id=123456
AND
version=3;
如果UPDATE的记录数为1,则表示成功。
如果UPDATE的记录数为0,则表示已经被其他连接UPDATE过了,需作异常处理。
- 数据库高并发下乐观锁的原理
- 高并发下乐观锁的原理
- 乐观锁解决高并发
- spring data jpa-纠错之旅-JPA高并发下的乐观锁异常 ObjectOptimisticLockingFailureException
- 关于高并发 悲观锁 乐观锁
- JPA使用乐观锁应对高并发
- web开发中的两把锁之数据库锁:(高并发--乐观锁、悲观锁)
- 高并发下的数据库并发控制策略
- 高并发下数据库优化
- 高并发下的程序设计,高并发下的数据库设计
- 高并发下的程序设计,高并发下的数据库设计
- 发锁事务重试机制(JPA高并发下的乐观锁异常)总结,以及中间遇到各种问题和解决方案
- 乐观锁与悲观锁的应用场景----处理高并发数据
- 大白话讲解并发控制的悲观锁与乐观锁 / 高性能 MySQL 笔记
- 数据库优化相关的知识,及高并发下的数据库优化,解决数据库并发瓶颈
- 高并发下的系统设计(偏数据库设计)
- 高并发下的数据库设计水平分区之一篇
- Hibernate的乐观锁并发控制机制
- UIViewController、UINavigationController、UITabBarController,这三者里面的控制器切换的区别?
- EasyUI学习之Combobox(一)
- JavaWeb开发环境搭建
- WEB安全测试之XSS
- Python 练习册,每天一个小程序-解答
- 数据库高并发下乐观锁的原理
- $(window).height()与$(document).height()
- js获取css样式
- iOS程序运行时_OBJC_CLASS_错误以及线程错误
- hdu 5279 YJC plays Minecraft 分治 NTT
- 修改数据后返回UITableView界面,Cell已创建但是表格不及时更新
- ios高德地图定位及定位后数据如何回调
- iOS 导航栏透明,变色动画
- Elasticsearch 5.1.1使用笔记,欢迎探讨