分布式事务的解决方案

XA模式：

2PC:存在的问题：

同步阻塞：当参与事务者存在占用公共资源的情况，其中一个占用了资源，其他事务参与者就只能阻塞等待资源释放，处于阻塞状态。

单点故障：一旦事务管理器出现故障，整个系统不可用

数据不一致：在阶段二，如果事务管理器只发送了部分 commit 消息，此时网络发生异常，那么只有部分参与者接收到 commit 消息，也就是说只有部分参与者提交了事务，使得系统数据不一致。

不确定性：当协事务管理器发送 commit 之后，并且此时只有一个参与者收到了 commit，那么当该参与者与事务管理器同时宕机之后，重新选举的事务管理器无法确定该条消息是否提交成功。

3PC加入预询盘和超时策略来解决单点故障问题并减少阻塞，如果因为协调者或网络问题，导致参与者迟迟不能收到来自协调者的 commit 或 rollback 请求，那么参与者将不会如两阶段提交中那样陷入阻塞，而是等待超时后继续 commit，相对于两阶段提交虽然降低了同步阻塞，但仍然无法完全避免数据的不一致。

TCC模式（柔性事务解决方案）：Try操作作为一阶段，负责资源的检查和预留，Confirm操作作为二阶段提交操作，执行真正的业务，Cancel是预留资源的取消

优势：

TCC执行的每一个阶段都会提交本地事务并释放锁，并不需要等待其他事务的执行结果．如果其他事务执行失败，则进行补偿操作而不是回滚操作，这样就避免了资源的长期锁定和阻塞等待，执行效率高．

缺点：

１．代码侵入性高，需要人为编写．try,confirm,cancel,代码侵入性高

２．开发成本高，一个业务需要拆分成３个步骤，分别编写业务实现

３．安全性，cancel如果失败，资源就无法释放，需要引入重试机制，而重试机制可能导致重复执行，还需要考虑幂等性问题

可靠消息服务

缺点，不会导致消息回滚，适用于主业务和附属业务的场景，最终一致性，时效性差，依赖于mq的可靠性

（１）本地消息表

（２）独立消息服务

AT模式（seata）

自动实现回滚和提交，底层拦截sql，保存before image和after image

角色：事务发起者，事务协调者（tc server），资源管理器