分布式事务
讲Seata之前,还是先来说下什么是分布式事务比较好,带着对分布式事务的了解,去看Seata会更有效一些。
分布式事务一直是企业集成开发的一个技术难点,也是每一个分布式系统架构都会设计到的东西,特别是在微服务架构中,几乎可以说是无法避免。
在微服务架构下,由于数据库和应用服务的拆分,导致原本一个事务单元中的多个DML操作,变成跨进程或者跨数据库的多个事务单元的多个DML操作,而传统的数据库事务无法解决这里问题,所以引出了分布式事务的概念。
要弄清楚分布式事务,就要搞清楚一下三个点,ACID,CAP,BASE理论。
ACID
指数据库事务正确执行的四个基本要素:
A:原子性(Atomicity)
C:一致性(Consistency)
I:隔离性(Isolation)
D:持久性(Durability)
具体的概念可以去看数据库的四大要素,这里不做概述,因为那些是基础的东西,到分布式这里默认已经对前面的基础框架知识有一定的储备。
CAP
CAP原则又称CAP定理,指的是在一个分布式系统中,一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)。
CAP原则指的是,这三个要最多只能同时实现两个,不可能三者兼顾。
- 一致性:在分布式系统中的所有数据备份,在同一时刻是否有同样的值。
- 可用性:在集群中,一部分节点故障后,集群整体是否还能相应客户的读写请求。
- 分区容错性:以实际结果而言,分区相当于对通信的时限要求,系统如果不能在时限内达成数据一致,就意味着发生了分区异常的情况,必须就当前操作在C和A之间做出选择。
BASE理论
BASE理论是对CAP中的一致性和可用性进行一个权衡的结果,理论的核心思想是:
我们无法做到强一致性,但每个应用可以根据自身的业务特点,采用适当的方式来使系统达到最终一致性。
- Basically Available(基本可用)
- Soft state(软状态)
- Eventually consistent(最终一致性)
分布式事务解决方案
目前常用的分布式解决方案大致有五种:
- 两阶段提交(2PC)
- 三阶段提交(3PC)
- 补偿事务(TCC=Try-Confirm-Cancel)
- 本地消息队列表(MQ)
- Saga事务模型(最终一致性)
对Seata的理解
seata事务处理就是基于以上五种解决方案进行了架构设计,更好的解决分布式事务。是阿里开源的分布式事务解决方案,提供了高性能且简单易用的分布式事务服务。
AT模式
AT模式,是一种基于本地事务+二阶段协议来实现的最终数据一致性方案,也是Seata的模式解决方案。
Saga模式
Saga模式时Seata提供的长事务解决方案,在Saga模式中,业务流程中的每个参与者都提交本地事务,当出现某一个参与者失败,则补偿前面已经成功的参与者。
TCC模式
TCC模式,是Try,Confirm,Cancel三个词语的缩写,简单的理解就是把一个完整的业务逻辑分成三个阶段,然后事务管理器在处理业务逻辑时,根据每个分支事务的执行情况,分别调用业务的Confirm或者Cancel方法。
XA模式
XA模式可以认为是一种强一致性解决方案,利用事务资源(数据库,消息任务等)对XA协议的支持,以XA协议的机制来管理分支事务的一种事务模式。