关于数据库事务和锁的一些分析

本文将针对以下几个问题给大家解答:

1)什么是事务?事务有哪些特性?

2)不同隔离级别的事务,有什么区别?

3)了解一下数据库锁:共享锁,更新锁,排它锁

4)数据库事务和锁之间有什么关系?

5)拓展:什么是分布式事务?有哪些解决方案?

 

事务

通常是指包含了多个数据库执行操作(select,update,delete,insert)的一个程序执行单元。

事务的四大特性ACID:

1.原子性(Atomicity):事务中所有数据库操作要么全部执行成功,要么全部执行失败。

2.一致性(Consistency):事务执行前后数据库状态保持一致。比如付款操作:A账户减少100元,相应的B账户增加100元。

3.隔离性(Isolation):事务与事务之间相互隔离,互不影响,保证了事务之间数据处理的独立性。

4.持久性(Durability):事务一旦提交成功,那么对数据库数据的影响必将持久化到数据库中,不会因为外在环境,比如断电,服务器宕机等因素而影响对数据库数据的变化。事务提交成功之后,会首先记录到数据库日志文件中,即使断电重启后,也会继续读取日志完成事务操作。

事务分类:根据事务中涉及的数据库操作实例数量区分

    本地事务:事务仅针对同一个数据实例进行操作, 例如:.Net中具体实现如SQLtransaction 

    分布式事务:事务中针对多个数据库实例进行操作。例如:.Net中的DTC分布式事务,具体实现TransactionScope

事务的隔离性,将事务分为不同隔离级别

1.未提交读(Read UnCommitted) :允许该事务读取其他事务未提交的数据。   

   存在问题:脏读

2.已提交读 (Read Committed):允许该事务读取其他事务已提交的数据。

   解决了脏读的问题

   存在问题:不可重复读,事务中前后读取数据不一致。

3.可重复读 (Repeatable Read):同一个查询,保证该事务读取前后数据一致。

   解决了不可重复度的问题

   存在问题:幻读 ,可能读取到其他事务新增的数据。

4.串行读(Serializable):要求事务序列化执行,事务只能一个接着一个地执行,不能并发执行。

   解决了幻读的问题

SQLServer数据库事务语法:

SET TRANSATION ISOLATION LEVEL READ UNCOMMITTED--设置事务隔离级别
BEGIN TRANSACTION
...
...--事务执行内容
...
COMMIT/ROLLBACK--提交或者回滚

数据库锁
1.共享锁(S)

1)保护读取的数据,读取的过程中,其他并发事务不能修改,删除数据,可以并发读取。

2)当事务隔离级别低于“可重复读”时,一旦数据读取结束,立即释放共享锁,和事务是否结束无关。

2.排它锁(X)

1)保护修改的数据,获取当前被修改资源的锁,该资源同一时刻只能被一个排它锁占有,不允许其他并发事务操作该资源(读取和修改)。

2)排它锁和共享锁不能兼容。当修改资源时,会自动由共享锁升级为排它锁,因此必须等待资源释放共享锁,才能获得排它锁。

3)如果排它锁存在于事务中,需等事务结束才能释放锁。

3.更新锁(U)

1)更新锁时介于共享锁和排它锁中间的混合。更新锁通过uplock手动添加,分两个阶段:1.在修改操作之前,通过更新锁获取资源对象 ,其他事务线程则只能读取不能操作  2.然后执行修改操作,将更新锁升级为排它锁。在修改操作前实现对资源锁定,避免了死锁。

2)更新锁和共享锁可以共存,因此使用更新锁比使用排它锁解决死锁问题,性能更优。

3)持有更新锁的资源,允许被其他并发事务select。

4)如果更新存在于事务中,需等事务结束才能释放更新锁。

事务与锁之间的关系

首先我们说事务和数据库锁之间没有必然的联系,但是事务的执行时间会影响锁持有的时间,间接影响了数据执行效率。

1.通常在执行select查询的时候会持有共享锁,查询一旦执行结束,则立即释放共享锁。如果在事务中执行查询,且隔离级别低于可重复读,即使事务没有执行结束,也不会影响共享锁的释放。

2.更新锁和排它锁,通常在语句执行结束后会立即释放锁资源。如果在事务中执行相关锁操作,需等待事务执行结束,才能释放锁。

3.update语句天然就会持有排它锁,即使不在事务中执行update操作也会持有锁。

4.事务隔离级别未提交读(Read UnCommitted)等同于select查询添加with(nolock),允许读取“脏数据”

语法:

select * from sys.objects with(nolock) where name='sysrscols';

5.事务隔离级别中的未提交读、已提交读和可重复读都是行级别锁,对条件范围内的行数据持有锁。

6.事务如何通过隔离级别处理并发,以“可重复读”隔离级别为例:

 1)事务A,默认隔离级别“已提交读”,查询操作5秒后执行更新操作

BEGIN TRAN
SELECT * FROM [ORDER] WHERE ID='10'
WAITFOR DELAY '00:00:05'
UPDATE [ORDER] SET PRICE=30 WHERE ID='10'
COMMIT TRAN

2)事务B,隔离级别“可重复读”,前后两次查询间隔10秒

SET TRAN ISOLATION LEVEL SERIALIZABLE
BEGIN TRAN
SELECT * FROM [ORDER] WHERE ID='10'
WAITFOR DELAY '00:00:10'
SELECT * FROM [ORDER] WHERE ID='10'
COMMIT TRAN

3)启动事务A后,立即启动事务B,事务具体执行顺序如下:

 a)事务A执行查询,并持有ID=10数据的共享锁,查询结束后释放锁,并等待5秒

 b)事务B执行查询,并持有ID=10数据的共享锁,由于隔离级别是可重复读,因此查询结束后也一直持有共享锁资源,并等待10秒。

 c)事务A5秒等待结束后,执行update申请持有ID=10数据的排它锁,此时事务B已经持有了共享锁,由于共享锁和排它锁互斥,所以事务A申请排它锁失败,继续等待事务B释放锁资源。这里其实也正是“可重复读”隔离级别解决“不可能重复”问题的关键。

 d)事务B10秒等待结束后,继续执行下一个select查询,并申请持有ID=10数据的共享锁,由于共享锁可以共存,事务B申请成功并完成查询,前后查询数据保持一致。

 e)事务A在事务B执行结束后,立即获取到ID=10数据的排它锁,并执行成功,事务A结束释放锁资源。

 

拓展:

锁分类:

  悲观锁:使用数据库锁机制,牺牲并发性能,保持事务一致性。

  乐观锁:不使用数据库锁机制,通常可通过操作前后校验数据的方式,比如字段中增加一个版本号version,如果更新前后版本号一致,则执行成功 否则返回错误提示,也能保证事务的一致性。

分布式事务

本地事务都是操作的本地单数据库,分布式事务中不同的操作可能涉及多个不同服务器上的数据库实例,因此本地事务不再满足。

解决方案:

1.两阶段提交(2PC)
准备阶段:事务协调者询问事务中的每个数据库参与者是否都执行事务成功,如果成功则进入下阶段。
提交阶段:事务协调者通知事务中每个参与者提交执行操作。
目前.Net中分布式事务支持TransactionScope 需启动MSDTC服务,即事务协调者。
特点:需要事务中涉及的每个参与者反馈成功才能最终提交,满足事务一致性,但是阻塞较长。

2.事务补偿机制(TCC)
该机制将事务中每个操作都注册对应的确认和补偿操作:分为三个阶段
1.try阶段:主要是对业务系统做检测和预留
2.confirm阶段:做确认提交,一旦try阶段成功,则默认confirm成功
3.cancel取消阶段:如果步骤执行失败,执行回滚。

3.本地事务+MQ消息
将分布式事务分为多个本地事务,不同服务器上的本地事务通过MQ消息发送。MQ分发的内容需要通过中间消息表进行记录并分发。满足事务最终一致性原则。
如:一个分布式事务中包含A,B两个不同数据库服务器上的操作,A操作执行本地事务+消息表记录B操作,MQ发送消息表信息,如果B服务器接收到信息,返回消息接收成功。那么A本地事务就会执行结束并提交。至于B服务器是否执行成功,A服务器不再关心。B服务器接收到消息之后,会在B本地事务执行,如果执行失败,则会一直重试,直到执行成功,以保持事务最终一致性。
其中如果A发送队列失败,也会重试发送。

posted @ 2021-08-03 15:40  跳跃的键盘手  阅读(251)  评论(0编辑  收藏  举报