java分布式事务总结

一.CAP原理 和BASE原理

C:一致性

A:可用性

P:分区容错性

在CAP理论基础上 有了 BASE柔性理论,即

(1).强一致性:要么一起成功,要么一起失败

(2).弱一致性:不要求数据立即一致,可以后中间状态

(3).最终一致性: 经过一段时间后,数据一致,包括 手动修改数据

二.两阶段 三阶段

 

(1)二阶段提交

参与的服务 ,有一个叫协调者,其他的是 参与者;

在准备提交事务时,协调者询问所有的参与者, 是否可以提交的 请求,

如果都返回yes就commit ,否则就回滚

如果超时也认为 失败

缺点

单点故障:如果协调者发生故障,参与者就会发生阻塞

同步阻塞: 一旦有一个参与者发生同步阻塞,所有操作都会发生阻塞

 

二阶段的实现XA 框架  ,java实现了XA的框架有 比较推荐 Atomikos 和 narayana,还有 seata

 

(2)三阶段提交

是非阻塞的,为解决二阶段的缺点设计,引入了超时机制,如果超时 也提交事务

在第一阶段 和第二阶段 之间新增了一个阶段 

CanCommit：协调者向所有参与者发送CanCommit命令，询问是否可以执行事务提交操作。如果全部响应YES则进入下一个阶段。

PreCommit：协调者向所有参与者发送PreCommit命令，询问是否可以进行事务的预提交操作，参与者接收到PreCommit请求后，如参与者成功的执行了事务操作，则返回Yes响应，进入最终commit阶段。一旦参与者中有向协调者发送了No响应，或因网络造成超时，协调者没有接到参与者的响应，协调者向所有参与者发送abort请求，参与者接受abort命令执行事务的中断。

DoCommit： 在前两个阶段中所有参与者的响应反馈均是YES后，协调者向参与者发送DoCommit命令正式提交事务，如协调者没有接收到参与者发送的ACK响应，会向所有参与者发送abort请求命令，执行事务的中断。

三.base柔性事务

 

(1). TCC模式

TCC 模式即将每个服务业务操作分为两个阶段，第一个阶段检查并预留相关资源，第二阶段根据所有服务业务的 Try 状态来操作，如果都成功，则进行 Confirm 操作，如果任意一个 Try 发生错误，则
全部 Cancel。
TCC 使用要求就是业务接口都必须实现三段逻辑：
1. 准备操作 Try：完成所有业务检查，预留必须的业务资源。
2. 确认操作 Confirm：真正执行的业务逻辑，不做任何业务检查，只使用 Try 阶段预留的业务资源。因此，只要 Try 操作成功，Confirm 必须能成功。另外，Confirm 操作需满足幂等性，保证一笔分布式事务能且只能成功一次。
3. 取消操作 Cancel：释放 Try 阶段预留的业务资源。同样的，Cancel 操作也需要满足幂等性。

框架:seata  hmily

注意:

1、允许空回滚   程序因为网络等原因try没有执行,直接执行confirm
2、防悬挂控制  程序因为网络等原因try执行晚于confirm实现
3、幂等设计

(2).saga

一个分布式事务 分成 多个本地事务 ,直接提交 没有 try ,然后在每个事务 提供一个 补偿的接口

 

(3).AT

(自动补偿处理)-tcc和saga的增强

根据前后的业务+sql,自动生成反向的sql,如果出现错误,就把之前修改的数据在修改回来,不用我们手动编写反向的sql,但是如果sql比较复杂的话,自动生成会有问题

框架 :seata 

 

四.框架

seata :实现了多个 模式