事务(三)

事物的安全问题

丢失更新:指一个事务去修改数据库,另一个事务也修改数据库,最后的那个事务,不管提交还是回滚都会造成前面一个事务的数据更新丢失。

解决办法:悲观锁乐观锁

悲观锁

指事务在一开始就认为丢失更新一定会发生,这是一件很悲观的事情。具体步骤如下:

1)所有事务在执行操作前,先查询一次数据, 查询语句如下:

        select * from student  for update  ;           后面的for update 其实是数据库锁机制 、 一种排他锁。

2) 哪个事务先执行这个语句, 哪个事务就持有了这把锁, 可以查询出来数据, 后面的事务再执行这条语句,不会有任何数据显示,就只能等着。 

3) 一直等到前面的那个事务提交数据后, 后面的事务数据才会出来,那么才可以往下接着操作。

这有点像男生去上卫生间似的, 如果谁先来,谁就可以进去蹲着, 后面来的人,得等着。 只有里面的人出来了,才能进去。 这其实就是 java 中的同步的概念

乐观锁

指从来不会觉得丢失更新会发生。那么它的具体做法是什么呢?

要求程序员在数据库中添加字段,然后在后续更新的时候,对该字段进行判定比对,如果一致才允许更新。例子如下:

1) 数据库表中,额外添加了一个version字段, 用于记录版本, 默认从0 开始, 只要有针对表中数据进行修改的,那么version就+1.

2) 开启A事务, 然后开启B事务 。 

3) A 先执行数据库表操作。 因为以前都没有人修改过。 所以是允许A事务修改数据库的,但是修改完毕,就把version的值变成  1 了 。

4)B事务, 这时候如果想执行修改,那么是不允许修改的。 因为B事务以前是没有查询过数据库内容的,所以它认为数据库版本还是0 。 但是数据库的版本经过A修改,已经是1了。所以这时候不允许修改, 要求其重新查询 。

5) B重新查询后, 将会得到version 为 1的数据,这份数据就是之前A 事务修改的数据了, B 在进行修改,也是在A的基础上修改的。 所以就不会有丢失更新的情况出现了。

乐观锁的机制 ,其实是通过比对版本或者比对字段的方式来实现的, 这与大家在未来的学习中,或者在工作中,使用到的版本控制软件【SVN , GIT】机制是一样的。

分布式事务阶段提交(Three-Phase Commit,3PC)是在传统的两阶段提交(Two-Phase Commit,2PC)基础上进行改进的一种分布式事务协议。它通过引入预备阶段来解决两阶段提交协议中的阻塞问题。 分布式事务阶段提交的过程如下: 1. CanCommit 阶段:事务协调者向所有参与者发送 CanCommit 请求,并等待参与者的回复。参与者在接收到 CanCommit 请求后,会执行本地的事务检查,判断是否可以提交事务。如果所有参与者都返回 Yes,则进入下一阶段;如果有任何一个参与者返回 No,则中止事务。 2. PreCommit 阶段:事务协调者向所有参与者发送 PreCommit 请求,并等待参与者的回复。参与者在接收到 PreCommit 请求后,会执行事务的预提交操作,并将预提交结果返回给事务协调者。如果所有参与者都返回 Acknowledgement,则进入下一阶段;如果有任何一个参与者返回 Abort,则中止事务。 3. DoCommit 阶段:事务协调者向所有参与者发送 DoCommit 请求,并等待参与者的回复。参与者在接收到 DoCommit 请求后,会执行事务的最终提交操作,并将提交结果返回给事务协调者。如果所有参与者都返回 Acknowledgement,则整个事务提交成功;如果有任何一个参与者返回 Abort,则整个事务被回滚。 分布式事务阶段提交相对于传统的两阶段提交协议,引入了预备阶段(PreCommit),在该阶段参与者可以执行预提交操作,但仍然需要协调者的最终确认才能进行最终提交。这样可以减少了阻塞等待的时间,提高了系统的并发性能。 然而,分布式事务阶段提交仍然存在一些问题,如单点故障、网络分区等情况下的可用性问题。因此,在实际应用中,需要综合考虑业务需求和系统特点,选择合适的事务协议来保证数据的一致性和可靠性。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值