分布式事务处理方案（CAP、Base、2PC、3PC、TCC、Saga）
一、CAP：一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）
CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。
一致性：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）。
可用性：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）。
分区容忍性：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。
CAP原则的精髓就是要么AP，要么CP，P是一定存在的，但是不存在CAP。如果在某个分布式系统中发生了网络分区状况或者宕机（触发了分区容忍性）， 那么系统分区之间的数据肯定不是一致的，如果系统要正常提供服务，那么就是牺牲了一致性，实现了可用性，这时候用户看到的数据就是不准确的（AP）。如果要保留一致性，那么系统就不能正常提供服务，直到分区之间的数据得到修复（CP）。
例如：A用户余额300元，B用户余额200元，A用户转账20元给B用户，此时收款服务执行成功，扣款服务执行失败；
AP：保留可用性；AB用户都能看到自己的余额，B用户收款成功看到的是220元，而A用户扣款失败看到的金额还是300元，此时的数据肯定是不一致的。
CP：保留一致性；短时间之内不提供AB用户的余额查询服务。直到数据修复完成（A用户280）。
二、Base：Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）
BASE是对CAP中一致性和可用性权衡的结果，其核心思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。
基本可用：指分布式系统在出现不可预知故障的时候，允许损失部分可用性。
弱状态：也称为软状态，和硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
最终一致性：强调的是系统中所有的数据副本或分区数据，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
三、2PC：二阶段提交(Two-phaseCommit)；
不适合在真实的分布式系统中使用，只适合单系统多数据库的场景。
我们常见的数据库连接事务中的 XA 是指由 X/Open 组织提出的分布式事务处理的规范. XA 规范主要定义了事务管理器(Transaction Manager)和局部资源管理器(Local Resource Manager)之间的接口。
XA接口提供资源管理器与事务管理器之间进行通信的标准接口，如：数据库事务的开始、结束以及提交、回滚等
XA协议采用两阶段提交方式来管理分布式事务。
事务阶段：
a、prepare准备阶段：确认服务正常、写提交事务日志。
b、commit提交阶段：提交事务日志到数据库。
缺点：
a、整个事务过程是同步阻塞的，占用资源，降低并发
b、数据可能出现不一致
c、单点故障
四、3PC：三阶段提交（Three-phase commit）
不适合在真实的分布式系统中使用，只适合单系统多数据库的场景。
相对于二阶段提交：
a、引入超时机制。同时在协调者和参与者中都引入超时机制。
b、在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。
事务阶段：
a、canCommit确认阶段：确认服务正常。
b、preCommit准备阶段：写提交事务日志。
c、doCommit提交阶段：提交事务日志到数据库。
缺点：
a、整个事务过程是同步阻塞的，相比二阶段提交，使用了超时机制
b、数据可能出现不一致
五、TCC：两阶段补偿（Try-Confirm-Cancel）预占、确认、取消
TCC是一种最终一致性的柔性事务方案，它在数据库表中单独使用一个字段来标识事务状态。
事务阶段：
a、Try阶段：新增数据（本地事务），状态设为“未提交”。如果事务参与者全都返回成功，则执行Commit，否则Cancel。
b、Commit阶段：提交数据，将a新增的数据状态设为“已提交”，如果任意一方出现异常，则执行Cancel。
Cancel阶段：删除数据，将a新增的数据状态设为“已撤销”，如果撤销失败，则记录下来，人工处理。
缺点：
a、实现复杂，业务复杂度高
b、数据可能出现不一致
六、Saga：（拆分事务+补偿机制）
Saga是一种最终一致性的柔性事务方案。分布式事务同步处理方案中较好的一种。
事务阶段：
a、Ti：通过子事务直接添加/修改数据，多个Ti的执行，如：T1、T2、T3、T4、、、Tn
b、Ci：针对Ti的补偿机制，多个Ci的执行，如：T1、T2、、、Tn、C1、C2、、、Cn
Saga的两种执行策略：
a、回退：如果有失败的子事务，则将成功了的子事务全部做补偿机制Ci。
b、重试：如果有失败的子事务，则继续重试，重试N次也不成功，则人工干预。这种方案针对必须成功的场景。