seate分布式锁三种模式

前言

        Seata分布式锁是分布式系统中的一种锁实现,主要用于控制不同进程共同访问共享资源。在分布式系统中,不同机器或主机之间可能共享某些临界资源,为了避免彼此之间的干扰和保证数据一致性,需要使用互斥机制来防止同时访问。Seata分布式锁的作用就是提供这种互斥机制。

Seata分布式锁具有以下特点:

1.互斥性:在任何时刻,对于同一项数据,只有一个客户端可以获取到分布式锁。
2.高可用性:在分布式场景下,一小部分服务器宕机不影响正常使用,这种情况就需要将提供分布式锁的服务以集群的方式部署。
3.防止锁超时:如果客户端没有主动释放锁,服务器会在一段时间之后自动释放锁,防止客户端宕机或者网络不可达时产生死锁。
4.独占性:加锁和解锁必须由同一个客户端进行,也就是锁的持有者才可以释放锁,不能出现非持有者解锁的情况。

        Seata分布式锁的解决方案主要有三种:关系型数据库、Redis和ZooKeeper。其中,Redis的分布式锁可以通过SETNX(SET if Not eXists)命令来实现,即先用SETNX来抢锁,如果抢到之后,再用expire给锁设置一个过期时间,防止锁忘记了释放。

1、Seate三种模式

1.Seate的XA模式(强一致性)

        开始TM向TC请求开启全局事务,TM调用每个RM分支,每个RM向TC注册自己分支事物,RM开始执行业务SQL,执行完成后,不提交事务并向TC报告事务的状态,业务执行完成后,TM向TC表明各个RM分支已经结束,此时TC检查分支事物的状态来决定是回滚还是进行提交事务。

1.1优缺点

优点:

(1)能够保证强一致性,满足ACID原则

(2)常用的数据库都支持,如mysql,实现比较简单且没有代码的侵入

缺点:

(1)因为第一阶段需要锁定资源等待其他分支执行完成,所以性能比较差

(2)依赖关系型数据库实现事物

2.Seate的AT模式(最终一致性)

        开始TM向TC请求开启全局事务,TM调用每个RM分支,每个RM向TC注册自己分支事物,RM开始执行业务SQL,执行完成后并提交事务,向TC报告自己的事物状态,在提交事务时会记录更新前后的快照到undo log表当中,TM发现事务完成后,向TC提交或回滚事务的请求,此时TC回去检查每个分支事务的情况,如果正常则删除undo log对应的数据,否则会通过undo log进行回滚。

        AT模型的脏写问题

        并发模式下,如果事务一先获取锁,将id为1的money由100减为了90,此时事务二进来,但获取不到锁,所以等待,事务一执行完毕后释放数据库锁,事务二此时获取到了锁,又将id为1的money由90减为80,此时事务一需要回滚,但是事务二正在获取锁,所以等待事务二释放锁后,事务一拿到锁后就根据undo log中的快照进行回滚,id为1的money此时就变为了原来的100,从而出现了脏写。

        解决方法

                情况一:

        在事务一执行业务SQL时,在提交事务前先获取全局锁,即将当前事务id和当前table(表)和当前行id进行记录,在执行完之后,事务二来修改,但在获取全局锁时发现已经有其他事务获取到了锁,所以会进行重试获取全局锁,此时如果事务一需要回滚,在获取数据库锁的时候就会失败,因为此时事务二占有数据库锁,但不会造成死锁,因为事务二在重试获取全局锁只有30次,并且每次10毫秒,所以当事务二获取全局锁失败后,就会进行事务回滚,此时事务一就占有了锁并进行回滚,所以此时回滚就不会照成脏写,因为事务二并没有成功更新。

                情况二:

        如果此时来更新此数据的事务并没有交给seata管理,所以在修改数据时,并不会去检查是否能获取全局锁,所以此时更新会成功,但解决方法是,在事务一对数据进行更新时会记录更新前数据和更新后的数据,如果事务一进行回滚时,会去将当前数据和事务一修改后的快照进行比较,如果相同则正常回滚,如果不同则会记录异常,发送警告,并进行人工介入,而不会进行正常的回滚。

2.1优缺点

优点:

(1)一阶段完成直接提交事务,释放数据库资源,性能比较好

(2)利用全局锁实现事务隔离

(3)没有代码侵入,框架自动完成回滚和提交

缺点:

(1)两阶段之间属于软状态,属于最终一致性

(2)框架的快照功能会影响性能,但比XA模式要好的多

3.TCC模式(最终一致性)

        通过将扣减的金额进行冻结(记录到一个表当中),如果进入到提交阶段,则删除冻结的余额,如果进入到回滚阶段则将冻结的金额重写添加到原来的数据当中。

        整体流程图

        TM向TC开启全局事务请求,然后调用各分支事务,RM注册分支事务,通过在Try中进行资源预留并提交事务,RM报告事务状态给TC,事务完成后,TM向TC告知事务执行完毕,TC就会去检查各分支事务的状态,来决定是进行confirm还是cancel,confirm删除预留资源,否则执行cancel删除预留资源并恢复可用资源。

        TCC模式的空回滚和业务悬挂问题

        允许空回滚的办法是在执行cancel时去判断try是否已经执行,如果已经执行则进行空回滚,而避免业务悬挂的办法是在执行try时去判断是否执行过了cancel,如果执行过了就不执行业务,就避免了悬挂。(0: try、1: confirm、2:cancel)

        Springboot整合Seata的TCC模式

        说明:获取全局事务id,可以使用Seata的RootContext.getXID()来获取

3.1优缺点

优点:

(1)一阶段完成直接提交事务,释放数据库资源,性能好。

(2)相比AT模型,无需生成快照,无需使用全局锁,性能最强。

(3)不依赖数据库事务,而是依赖补偿操作,可以用于非事务型数据库。

缺点:

(1)有代码侵入,需要人为编写try、confirm、cancel接口,太麻烦

(2)软状态,事务是最终一致性

(3)需要考虑confirm和cancel的失败情况,做好幂等性处理

  • 22
    点赞
  • 27
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

爱生活,更爱技术

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值