seata的四种模式

首先吧 分布式事务使用的场景有限 因为引入分布式事务需要考虑比较多的复杂性 所以推荐在能用本地事务解决的情况下 尽量避免使用分布式事务

如果决定要使用分布式事务 则需要小心考虑业务场景是否能避开分布式事务的缺陷

分布式事务有很多解决方案 多数情况下原理相似 这里以seata为例 通过分析seata的四种模式 来窥探分布式事务的复杂性

四种模式都采用2阶段提交的模型(Two-phase Commit,2PC)​ 大概就是 1阶段本地提交 2阶段全局提交或回滚

AT模式 生产上最有可能使用的模式,基本上做到了业务上零入侵。1阶段本地提交依赖如mysql的acid事务,本质就是本地commit。1阶段提交后,同时seata的事务框架会持久化数据变更前和变更后的信息。2阶段在事务框架确认没有问题的后就全局提交(因为数据在1阶段已经真实提交了,所以此时只是删除掉存储的变更信息),2阶段如果发生问题,就执行全局回滚,此时就用上了存储的变更信息,自动生成回滚的sql,并执行。

这里有些概念要注意 seata自带了一个事务框架 里面大概涉及到全局锁 事务协调器 事务管理器之类的组件 但是都属于seata层级的 和数据库本身的事务并无关系(XA模式例外)。

到这里,其实二阶段提交的模型已经体现出来了。剩下3种模式 大体框架也是这样 只是在提交 回滚 事务管理 上的实现有区别。

AT模式:数据库1阶段本地提交 2阶段自动回滚 使用全局锁
TCC模式:自定义提交 自定义回滚 不依赖数据库本身的事务 使用全局锁
SAGA模式:和TCC模式基本相同 也是提交和回滚自定义 但是有个重要的区别:在全局事务管理中 没有用全局锁 这就意味着saga模式没法保证写的隔离性
XA模式:依赖数据库的XA协议 与AT模式思路是一样的 只不过提交和回滚对接了数据库的XA协议 由XA协议保证提交和回滚(AT模式的提交和回滚由seata定义的事务管理器处理) 且XA是强一致的(XA协议提供,XA协议的全局锁是读写隔离的,所以XA是长事务模式)

通过以上模式 可以总结一些知识点:
1.seata分部式事务总体是基于2阶段提交的
2.基于2阶段提交的分布式事务 除XA模式外 存在 读未提交 的问题
3.AT TCC XA都使用了全局锁 可以保证写隔离(不会发生脏写),SAGA没用使用全局锁,会出现脏写问题
4.除AT XA模式,其他模式对业务代码入侵性强,增加了开发成本和代码复杂度。

通过以上总结的知识点,不难看出seata使用场景有限的原因。除XA外的3种模式都有 读未提交 的问题,XA模式虽然读写隔离,但是属于长事务模式,性能较本地提交很差。这不是seata独有的问题,应该说是分布式事务模型存在的缺陷,故在选择分布式事务的情况下,要考虑的方面比较多。

在实际业务场景上,核心业务很难接受读未提交带来的后果,宁愿牺牲性能也要尽可能保证数据的一致性。边缘业务由于数据没那么重要,用分布式事务这种相对较重的方案,也显得没那么必要。综上所述,seata就显得有点鸡肋。

在核心业务中,为保证强一致和性能,一种方案是在微服务划分的时候,把核心业务尽量划分为一个整体(即一个服务),然后用本地提交保证性能。也可以使用分布式锁或数据库字段标识 加上 数据库本地事务来保证强一致性。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值