分布式事务
：
就是指事务的参与者、支持事务的服务器、资源服务器以及事务
管理器分别位于不同的分布式系统的不同节点之上。简单来说，分布式事务指
的就是分布式系统中的事务，它的存在就是为了保证不同数据库节点的数据一
致性。
聊到分布式事务，大家记得这两个理论哈：
CAP
理论 和
BASE
理论
分布式事务的几种解决方案：
- 2PC(二阶段提交)方案、3PC
- TCC（Try、Confirm、Cancel）
- 本地消息表
- 最大努力通知
- seata
2PC(
二阶段提交
)
方案
2PC
，即两阶段提交，它将分布式事务的提交拆分为
2
个阶段：
prepare
和
commit/rollback
，即准备阶段和提交执行阶段。在
prepare
准备阶段需要等待
所有参与子事务的反馈，因此可能造成数据库资源锁定时间过长，不适合并发
高以及子事务生命周长较长的业务场景。并且协调者宕机，所有的参与者都收
不到提交或回滚指令。
3PC
两阶段提交分别是：
CanCommit
，
PreCommit
和
doCommit
，这里不再详述。
3PC
利用超时机制解决了
2PC
的同步阻塞问题，避免资源被永久锁定，进一步加强
了整个事务过程的可靠性。但是
3PC
同样无法应对类似的宕机问题，只不过出
现多数据源中数据不一致问题的概率更小。
TCC
TCC
采用了补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应
的确认和补偿（撤销）操作。它分为三个阶段：
Try-Confirm-Cancel
try
阶段：尝试去执行，完成所有业务的一致性检查，预留必须的业务资源。
Confirm
阶段：该阶段对业务进行确认提交，不做任何检查，因为
try
阶段已经检
查过了，默认
Confirm
阶段是不会出错的。
Cancel
阶段：若业务执行失败，则进入该阶段，它会释放
try
阶段占用的所有业
务资源，并回滚
Confirm
阶段执行的所有操作。
TCC
方案让应用可以自定义数据库操作的粒度，降低了锁冲突，可以提升性能。
但是应用侵入性强，
try
、
confirm
、
cancel
三个阶段都需要业务逻辑实现。
本地消息表
ebay
最初提出本地消息表这个方案，来解决分布式事务问题。业界目前使用
这种方案是比较多的，它的核心思想就是将分布式事务拆分成本地事务进行处
理。可以看一下基本的实现流程图：
最大努力通知
最大努力通知方案的目标，就是发起通知方通过一定的机制，最大努力将业务
处理结果通知到接收方。
seata
Saga
模式是
Seata
提供的长事务解决方案。核心思想是将长事务拆分为多个
本地短事务，由
Saga
事务协调器协调，如果正常结束那就正常完成，如果某
个步骤失败，则根据相反顺序一次调用补偿操作。
Saga
的并发度高，但是一致性弱，对于转账，可能发生用户已扣款，最后转
账又失败的情况
![[python][学习]循环与嵌套---打印乘法口诀](https://img-blog.csdnimg.cn/05e15267dbd841d392683f07ecc61909.png)
