sql server对并发的处理-乐观锁和悲观锁
假如两个线程同时修改数据库同一条记录,就会导致后一条记录覆盖前一条,从而引发一些问题。
例如:
一个售票系统有一个余票数,客户端每调用一次出票方法,余票数就减一。
情景:
总共300张票,假设两个售票点,恰好在同一时间出票,它们做的操作都是先查询余票数,然后减一。
一般的sql语句:
1
2
3
4
5
6
7
8
9
|
declare @ count as int begin tran select @ count = count from ttt WAITFOR DELAY '00:00:05' --模拟并发,故意延迟5秒 update ttt set count =@ count -1 commit TRAN SELECT * FROM ttt |
问题就在于,同一时间获取的余票都为300,每个售票点都做了一次更新为299的操作,导致余票少了1,而实际出了两张票。
打开两个查询窗口,分别快速运行以上代码即可看到效果。
定义解释:
悲观锁:相信并发是绝大部分的,并且每一个线程都必须要达到目的的。
乐观锁:相信并发是极少数的,假设运气不好遇到了,就放弃并返回信息告诉它再次尝试。因为它是极少数发生的。
悲观锁解决方案:
1
2
3
4
5
6
7
|
declare @ count as int begin tran select @ count = count from tb WITH (UPDLOCK) WAITFOR DELAY '00:00:05' --模拟并发,故意延迟5秒 update tb set count =@ count -1 commit tran |
在查询的时候加了一个更新锁,保证自查询起直到事务结束不会被其他事务读取修改,避免产生脏数据。
从而可以解决上述问题。
乐观锁解决方案:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
--首先给表加一列timestamp ALTER TABLE ttt ADD timesFlag TIMESTAMP NOT null 然后更新时判断这个值是否被修改 declare @ count as int DECLARE @flag AS TIMESTAMP DECLARE @rowCount AS int begin tran select @ count = COUNT ,@flag=timesflag from ttt WAITFOR DELAY '00:00:05' update ttt set count =@ count -1 WHERE timesflag=@flag --这里加了条件 SET @rowcount=@@ROWCOUNT --获取被修改的行数 commit TRAN --对行数进行判断即可 IF @rowCount=1 PRINT '更新成功' ELSE PRINT '更新失败' |
这便是乐观锁的解决方案,可以解决并发带来的数据错误问题,但不保证每一次调用更新都成功,可能会返回'更新失败'
悲观锁和乐观锁
悲观锁一定成功,但在并发量特别大的时候会造成很长堵塞甚至超时,仅适合小并发的情况。
乐观锁不一定每次都修改成功,但能充分利用系统的并发处理机制,在大并发量的时候效率要高很多。
好文要转!
原文转至:http://www.cnblogs.com/dengshaojun/p/3955826.html
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 为什么说在企业级应用开发中,后端往往是效率杀手?
· 用 C# 插值字符串处理器写一个 sscanf
· Java 中堆内存和栈内存上的数据分布和特点
· 开发中对象命名的一点思考
· .NET Core内存结构体系(Windows环境)底层原理浅谈
· 为什么说在企业级应用开发中,后端往往是效率杀手?
· 本地部署DeepSeek后,没有好看的交互界面怎么行!
· DeepSeek 解答了困扰我五年的技术问题。时代确实变了!
· 趁着过年的时候手搓了一个低代码框架
· 推荐一个DeepSeek 大模型的免费 API 项目!兼容OpenAI接口!