1. CAP理论
C: Consistency 一致性
A: Availability 可用性
P: Partition tolerance 分区容错性
CAP定理：一个分布式系统不可能同时满足CAP三个要求，最多只能同时满足其中两项。
1.1. CA:
放弃分区容错性，所有数据放一个节点，退回单机模式。
1.2. CP:
放弃可用性，一旦网络故障，受影响服务需要等待恢复时间，系统处于不可用状态。
1.3. AP:
放弃一致性，这里指放弃强一致性，确保最终一致性。大多数分布式系统的选择。
2. BASE理论
BASE: Base Available(基本可用)，Soft state(软状态), Eventually consistent(最终一致性)。
BASE是对CAP一致性和可用性权衡的结果。
1. 基本可用：指分布式系统出现不可预知故障时，允许损失部分可用性，响应时间合理延长，服务上适当降级。
2. 软状态: 允许分布式系统中的数据处于中间状态，允许各节点数据同步时存在延时。
3. 最终一致性：允许系统中所有数据副本，在经过一段时间同步后，最终能够达到一个一致的状态。不需要实时保证系统的数据一致性。
3. 两阶段提交(2PC)
数据库支持2PC，又叫XA transactions。
MySQL从5.5版，Oracle从7版，SQL Server 2005开始支持。
XA是一个两阶段提交协议，协议分两阶段：
第一阶段：事务协调器要求每个涉及到事务的数据库预提交/投票(pre commit)此操作，并反映是否可以提交。
第二阶段：事务协调器要求每个数据库提交数据。
如果有任何一个数据库否决此次提交，那么所有数据库都会被要求回滚它们在此事务中的那部分信息。
预提交/投票阶段：
事务协调者(事务管理器)给每个参与者(资源管理器)发送 Prepare 消息，每个参与者要么直接返回失败(如权限验证失败)，
要么在本地执行事务，写本地的 redo 和 undo 日志，但不提交。
提交阶段：
如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(Rollback)消息；
否则，发送提交(Commit)消息；参与者根据协调者的指令执行提交或者回滚操作，释放所有事务处理过
程中使用的锁资源。(注意:必须在最后阶段释放锁资源)
2PC缺点：
1. 同步阻塞。 执行过程中，所有节点都是事务阻塞的。
2. 单点故障。
2.1. 协调者正常，参与者宕机
协调者无法收集到所有参与者反馈，会陷入阻塞。
2.2. 协调者宕机，参与者正常
无论哪个阶段，协调者挂了，则无法发送提交请求，参与者会陷入阻塞。
2.3. 协调者与参与者都宕机
1). 发生在第一阶段，由于参与者都没有真正commit，则可以重新选出协调者，再执行2PC。
2). 发生在第二阶段，并且挂了的参与者在挂之前并没有收到协调者指令。这种情况，新的协调者重新执行2PC。
3). 发生在第二阶段，有部分参与者已经commit，产生数据不一致(脑裂)。2PC无法解决！
4). 协调者发出commit后挂了，唯一接收到这条消息的参与者同时也挂了。则即使选举出新的协调者，这条事务状态也不确定，没人知道事务是否被已经提交。
4. 三阶段提交（3PC）
3PC是2PC的改进版。
3PC改进点：
1. 同时在协调者和参与者引入超时机制。
2. 在2PC的第一阶段和第二阶段中插入一个准备阶段，保证了在最后提交阶段之前各参与者状态时一致的。
3PC有CanCommit, PreCommit, DoCommit三个阶段。
1. CanCommit阶段：
2PC的第一阶段是本地事务执行结束后，最后不Commit。3PC的CanCommit是指尝试获取数据库锁，如果可以就返回Yes，进入预备状态，否则返回No。
2. PreCommit阶段：
如果上一阶段所有参与者都返回Yes，则进入PreCommit阶段进行事务预提交。这里协调者和参与者都引入超时机制。
假如有任何一个参与者向协调者发送No，或者等待超时之后，协调者还没有收到参与者响应，则执行事务中断。
3. DoCommit阶段：
真正进行事务提交。
包括 1. 协调者发送提交请求；2.参与者提交事务；3.参会者响应反馈(向协调者发送ACK)；4.协调者确定事务完成。
5. TCC事务
TCC: Try / Confirm / Cancel，可归纳为补偿型事务。
核心思想：针对每个操作，都有有一个与其对应的确认和补偿(撤销)操作。
Try: 针对业务操作做检测(一致性)和资源预留(隔离性)。
Confirm:对业务进行确认提交。默认Try成功并开始执行Confirm，Confirm一定成功。
Cancel: 在业务执行错误，需要回滚时执行业务补偿，释放预留资源。
TCC优点：
1. 解决协调者单点故障的问题。
2. 引入超时后进行补偿，并不会锁定整个资源，事务颗粒的变小。
3. 通过补偿机制，由业务操作管理数据一致性。
TCC缺点： 开发复杂，每个目标字段都需要一个预留(冻结)字段，需要写很多补偿代码，在一些业务场景不太好定义和处理。
TCC使用场景：钱，金融等对事务要求非常高的核心业务场景。
总结： TCC使用于大部分接口是同步调用的场景，要么一起成功，要么一起回滚。但在实际系统中，可能服务之间的调用时异步的，通过消息中间件。
来源：https://www.cnblogs.com/fyql/p/12040616.html