分布式事务

项目中分布式事务的问题：*****

因为是微服务项目，文章模块和自媒体模块分别对应着不同的数据库，这样就会产生不同的数据库连接。如果自媒体微服务通过feign调用文章微服务的保存方法后，若出现了异常，自媒体微服务会进行事务的回滚。而文章微服务因为是不同的数据库连接，所以不会发生事务的回滚，这样就会造成数据不一致的问题。

解决分布式事务的方法：*****

在该项目中，我们是采取子事务+全局事务的方式解决分布式事务的。主要使用的是阿里巴巴的开源框架seata，采取的AT模式。项目中分布式事务主要分成两个阶段执行：

1. 事务管理器（TM）开启全局事务，之后开始调用分支，并让TC注册分支事务。分支事务注册后，执行sql并提交，并记录数据更新前后的快照到undo log表中。然后向TC报告分支事务的执行状态。
2. 事务管理器发出提交、回滚全局事务的指令，TC接收指令后会根据各个分支事务提交的状态报告进行判断，如果所有分支都成功，则提交全局事务，否则有一个事务失败，都会回滚全局事务。

使用AT模式的好处在于不会产生死锁，因为sql执行之后就提交了，释放了锁资源。保证了数据的最终一致性。开启的注解是 @GlobalTransactional。

PS：seata支持的模式有XA、AT、SAGA、TCC。XA和AT不一样的地方在于AT执行完sql之后会释放锁资源，而XA不会。所以XA的性能较差。SAGA适合长连接。TCC一阶段预留资源、二阶段提交或回滚。

分布式事务理论：****

CAP定理：

- Consistency（一致性）：用户访问分布式系统中的任意节点，得到的数据必须一致。

- Availability（可用性）：节点必须健康可用，必须得到响应

- Partition tolerance （分区容错性）：受网络影响，集群节点间通信失败，会产生分区。此时系统也要对外提供服务，保持可用，这是容错性。

分布式事务的解决思路：（还有上面的子事务和全局事务）

在分布式环境下，分区容错性要得到保证。因为网络是不可靠的，没办法避免。一般情况下，我们都是优先保证的AP，在保证系统可用的前提下，可能会出现临时的数据不一致的现象。但是只要最终的结果是一致的就可以了。后期数据可以人工修改，类似于天猫双十一优先保证下单支付，关闭一些其他非核心的功能。而CP则是必须要等待集群节点数据同步完了之后才对外提供服务，保证了一致性，失去了可用性。

CA的情况不可能会出现，因为保证了一致性势必会牺牲可用性，反过来也是如此。

BASE理论：***

对CAP的一种补充，放弃强一致性，追求最终一致性。它有三种思想。

1. 基本可用：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。
2. 软状态：在一定时间内，允许出现中间状态，比如临时的不一致状态。
3. 最终一致性：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。