分布式事务几种方案(初识分布式事务)

2024-01-09 23:23:33

基础理论

一、CAP

CAP原则又称CAP定理,指的是在一个分布式系统中,一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)。 CAP原则的精髓就是要么AP,要么CP,要么AC,但是不存在CAP。

?

二、BASE理论

?

三、事务类型

??1、刚性事务

??遵循 ACID 原则,强一致性

??2、柔性事务

??遵循 BASE 理论,最终一致性与刚性事务不同,柔性事务允许一定时间内,不同节点的数据不一致,但要求最终一致。

模型

一、2PC 模式(刚性事务)

1、介绍

数据库支持的 2PC【2 phase commit 二阶提交】,又叫做 XA Transactions。MySQL 从 5.5 版本开始支持,SQL Server 2005 开始支持,Oracle 7 开始支持。

  • 其中,XA 是一个两阶段提交协议,该协议分为以下两个阶段:

    ??其中,如果有任何一个数据库否决此次提交,那么所有数据库都会被要求回滚它们在此事务中的那部分信息。

    • 第一阶段:事务协调器要求每个涉及到事务的数据库预提交(precommit)此操作,并反映是 否可以提交.

    • 第二阶段:事务协调器要求每个数据库提交数据。

?

2、优缺点

  • 成本低,维护简单

  • XA 性能不理想,特别是在交易下单链路,往往并发量很高,XA 无法满足高并发场景

  • XA 目前在商业数据库支持的比较理想,在 mysql 数据库中支持的不太理想,mysql 的 XA 实现,没有记录 prepare 阶段日志,主备切换回导致主库与备库数据不一致。

  • 许多 nosql 也没有支持 XA

3、示例的框架

  • Seata

二、TCC 事务补偿型方案(柔性事务)

?

1、三阶段介绍

  • prepare 阶段主要是对业务系统做检测及资源预留

  • commit 阶段主要是对业务系统做确认提交,Try阶段执行成功并开始执行commit 阶段时,默认commit 阶段是不会出错的。即:只要prepare 成功,commit 一定成功。若commit 阶段真的出错了,需引入重试机制或人工处理。

  • rollback 阶段主要是在业务执行错误,需要回滚的状态下执行的业务取消,预留资源释放

2、总结

  • 三阶段都调用自定义阶段的业务处理逻辑,即所谓 TCC 模式,是指支持把 自定义 的分支事务纳入到全局事务的管理中。

3、优缺点

  • 代码侵入性很强,维护成本很高

  • 实现难度也不小,回滚策略实现并不简单

  • 能够全程自定义行为

  • 流量承受能力一般

4、框架

??4.1、Hmily

????Hmily是一个高性能分布式事务tcc开源框架。基于java语言来开发(JDK1.8),支持dubbo,springcloud,motan等rpc框架进行分布式事务。

??4.2、Seata

三、最大努力通知型方案(柔性事务)

1、实现例子

  • 按规律进行通知,不保证数据一定能通知成功,但会提供可查询操作接口进行核对。这种方案主要用在与第三方系统通讯时,比如:调用微信或支付宝支付后的支付结果通知。这种方案也是结合 MQ 进行实现,例如:通过 MQ 发送 http 请求,设置最大通知次数。达到通知次数后即不再通知。

2、 典型案例

  • 微信支付回调

3、优缺点

  • 数据一致一般

  • 可承受高并发流量

  • 有一定的代码入侵性

四、可靠消息+最终一致性方案异步确保型(柔性事务)

1、实现

  • 业务处理服务在业务事务提交之前,向实时消息服务请求发送消息,实时消息服务只记录消息数据,而不是真正的发送。业务处理服务在业务事务提交之后,向实时消息服务确认发送。只有在得到确认发送指令后,实时消息服务才会真正发送。

2、防丢失手段

  • 做好消息确认机制(pulisher,consumer【手动 ack】)

  • 每一个发送的消息都在数据库做好记录。定期将失败的消息再次发送一 遍

3、优缺点

  • 可承受高并发流量

  • 最终数据一致性较高

  • 有一定的代码入侵性

4、案例基于消息队列完成库存解锁

文章来源:https://blog.csdn.net/weixin_54498224/article/details/135415749
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。