分布式事务几种方案(初识分布式事务)
基础理论
一、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、案例基于消息队列完成库存解锁
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。 如若内容造成侵权/违法违规/事实不符,请联系我的编程经验分享网邮箱:veading@qq.com进行投诉反馈,一经查实,立即删除!