seata

常见分布式事务解决方案

1.seata阿里分布式事务框架

2.消息队列

3.saga

4.XA

他们都有一个共同点，都是"两阶段（2PC）"， “两阶段”是指完成整个分布式事务，划分为两个步骤完成。

实际是上，这是四种常见的分布式解决方案，分别对应着分布式事务的四种模式：AT，TCC, Saga， XA;

四种分布式事务模式，都有各自的理论基础，分别在不同的时间被提出；每种模式都有它的适用场景，同样每个模式也都诞生有各自的代表产品；而这些代表产品，可能就是我们常见的（全局事务，基于可靠消息，最大努力通知，TCC）。

今天，我们会分别来看4种模式（AT， TCC， Saga， XA）的分布式事务实现。

2pc的问题

1.同步阻塞 参与者在等待协调者指令时，其实是在等待其他参与者的响应，在此过程中，参与者是无法进行其他操作的，也就是阻塞il其运行。倘若参与者协调者之间网络异常导致参与者一直收不到协调者信息，那么会导致参与者一直阻塞下去。
2.单点 在2pc中，一切请求都来自协调者，所以协调者的地位是至关重要的，如果协调者宕机，那么就会使参与者一直阻塞占用事务资源。如果协调者也是分布式，使用选主方式提供服务，那么在一个协调者挂掉后，可以选取另一个协调者继续后续的服务，可以解决单点问题，但是，新协调者无法知道上一个事务的全部状态信息（例如已等待 Prepare响应的时长等），所以无法顺利处理上一个事务。

3.数据不一致 Commit事务过程中Commit请求/Rollback请求可能因为协调者宕机或者协调者与参与者网络问题丢失，那么就导致了部分参与者没有收到Commit/Rollback 请求，而其他参与者则正常执行了Commit/Rollback操作，没有收到请求的参与者则继续阻塞。这时，参与者之间的数据就不再一致了。

当参与者执行Commit/Rollback后会向协调者发送Ack，然后协调者不论是否收到所有参与者的Ack，该事务也不会再有其他补救措施了，协调者能做的也就是等待超时后向事务发起者返回一个”我不确定该事务是否成功“。

4.环境可靠性依赖协助者 Prepare请求发出后，等待响应，然而如果有参与者宕机或者与协助者之间的网络中断。都会导致协调者无法收到所有参与者的响应，那么在 2PC 中，协调者会等待一定时间，然后超时后，会触发事务中断，在这个过程中，协调者和所有参与者都是出于阻塞的。这种机制对网络问题常见的现实环境来说太苛刻了

AT模式（auto transaction）

AT模式是一种无侵入的分布式事务解决方案

阿里seata框架，实现了该模式

在AT模式下，用户只需关注自己的"业务SQL"，用户的"业务SQL"作为一阶段，Seat框架会自动生成事务的二阶段提交和回滚操作。