1. CAP定理
CAP是指一致性（Consistency）、可用性（Availability）和分区容忍性（Partition Tolerance）三个属性，它们是分布式系统设计中的重要概念。
● 一致性（Consistency）：
在分布式系统中的所有数据结点，在同一时刻是否同样的值。如果在某个节点更新了数据，那么在其他节点如果都能读取到这个最新的数据，那么就称为强一致，如果有某个节点没有读取到，那就是分布式不一致；
● 可用性（Availability）：
在集群中一部分节点故障后，非故障的节点在合理的时间内返回合理的响应。合理的时间指的是请求不能无限被阻塞，应该在合理的时间给出返回；合理的响应指的是系统应该明确返回结果并且结果是正确的；
● 分区容错性（Partition Tolerance）：
系统能够在节点之间发生网络分区（Partition）的情况下仍然能够正常运行；
对于CP来说，放弃可用性，追求一致性（强一致性）和分区容错性；对于AP来说，放弃一致性，追求分区容错性和可用性，这是很多分布式系统设计时的选择，BASE是根据AP来扩展。在实际应用中，网络延迟和不可靠性是不可避免的，数据复制和同步需要一定的时间。因此，即使选择了保证一致性和分区容忍性（CP），在发生网络分区时，节点之间的数据复制可能会产生一定的延迟，导致节点之间的数据不一致，所以很多业务场景我们退而求用户能接受时间延迟的最终一致方案。
2. BASE理论
根据CAP定理，如果要完整的实现事务的ACID特性，只能放弃可用性选择一致性，然而可用性在现在互联网环境至关重要，BASE 理论是对 CAP 中一致性和可用性权衡的结果，是CAP中AP的一个扩展。其核心思想是：强一致性无法得到保障时，我们可以根据业务自身的特点，采用适当的方式来达到最终一致性。BASE 是 Basically Available（基本可用）、Soft State（软状态）和 Eventually Consistent （最终一致性）三个短语的缩写。
● BA：（Basically Available）基本可用性，分布式系统在面对故障或分区的情况下，仍然能够保证基本的可用性。即系统可以继续运行并提供核心的功能，而不是完全崩溃；
● S：（Soft State）软状态，分布式系统中的数据状态不需要实时保持一致，而是允许一段时间的数据不一致。数据状态可以是中间状态，可以根据系统自身的需要而变化，这种状态允许一定的延迟和不一致性；
● E：（Eventually Consistent）最终一致性，经过一段时间后数据最终会达到一致状态，但不要求实时的一致性。
3. 2PC 两阶段提交
阶段一：提交事务请求
协调者向参与者发送事务询问。协调者向所有参与者发送事务内容，询问是否可以执行提交操作，并开始等待各参与者进行响应；
参与者执行事务操作。各参与者节点，执行事务操作，并将Undo和Redo操作计入本机事务日志；
各参与者反馈事务询问。成功执行返回Yes，否则返回No。
阶段二：执行事务提交，或者执行中断事务
这一阶段包含两种情形：
协调者执行事务提交
协调者执行中断事务
协调者在阶段二决定是否最终执行事务提交操作。
所有参与者reply Yes，那么执行事务提交。
当存在某一参与者向协调者发送No响应，或者等待超时。协调者只要无法收到所有参与者的Yes响应，就会中断事务。
4. 3PC 三阶段提交
3PC 协议将 2PC 协议的准备阶段一分为二，从而形成了三个阶段。
所谓的三个阶段分别是：询问，然后再锁资源，最后真正提交。
阶段一：CanCommit
协调者向参与者发送事务询问。协调者向所有参与者发送包含事务内容的canCommit的请求，询问是否可以执行事务提交，并等待应答；
各参与者反馈事务询问。正常情况下，如果参与者认为可以顺利执行事务，则返回Yes，否则返回No。
阶段二：PreCommit
在本阶段，协调者会根据上一阶段的反馈情况来决定是否可以执行事务的PreCommit操作。有以下两种可能：
执行事务预提交
中断事务
执行事务预提交
协调者向参与者发送预提交请求。协调者向所有节点发出PreCommit请求，并进入prepared阶段；
参与者执行事务操作。参与者收到PreCommit请求后，会开始事务操作，并将Undo和Redo日志写入本机事务日志；
各参与者成功执行事务操作，同时将反馈以Ack响应形式发送给协调者，同事等待最终的Commit或Abort指令。
中断事务
如果任意一个参与者向协调者发送No响应，或者等待超时，协调者在没有得到所有参与者响应时，即可以中断事务。
中断事务的操作为：
发送中断请求。 协调者向所有参与者发送Abort请求；
中断事务。无论是参与者收到协调者的Abort请求，还是参与者等待协调者请求过程中出现超时，参与者都会中断事务；
阶段三：doCommit
在这个阶段，会真正的进行事务提交，同样存在两种可能。
执行提交
回滚事务
执行提交
协调者发送提交事务请求。假如协调者协调者收到了所有参与者的Ack响应，那么将从预提交转换到提交状态，并向所有参与者，发送doCommit请求；
参与者执行事务提交。参与者收到doCommit请求后，会正式执行事务提交操作，并在完成提交操作后释放占用资源；
参与者反馈事务提交结果。参与者将在完成事务提交后，向协调者发送Ack消息；
完成事务。协调者接收到所有参与者的Ack消息后，完成事务。
回滚事务
在该阶段，假设正常状态的协调者接收到任一个参与者发送的No响应，或在超时时间内，仍旧没收到反馈消息，就会回滚事务：
协调者发送中断请求。协调者向所有的参与者发送rollback请求；
参与者执行事务回滚。参与者收到rollback请求后，会利用阶段二中的Undo消息执行事务回滚，并在完成回滚后释放占用资源；
参与者反馈事务回滚结果。参与者在完成回滚后向协调者发送Ack消息；
完成事务回滚。协调者接收到所有参与者反馈的Ack消息后，完成事务回滚。
5. TCC（Try-Confirm-Cancel）
针对一个具体的业务服务，TCC 分布式事务模型需要业务系统提供三段业务逻辑：
初步操作 Try：完成所有业务检查，预留必须的业务资源。
确认操作 Confirm：真正执行的业务逻辑，不作任何业务检查，只使用 Try 阶段预留的业务资源。因此，只要 Try 操作成功，Confirm 必须能成功。另外，Confirm 操作需满足幂等性，保证一笔分布式事务有且只能成功一次。
取消操作 Cancel：释放 Try 阶段预留的业务资源。同样的，Cancel 操作也需要满足幂等性。
Try 阶段： 调用 Try 接口，尝试执行业务，完成所有业务检查，预留业务资源。
Confirm 或 Cancel 阶段： 两者是互斥的，只能进入其中一个，并且都满足幂等性，允许失败重试。
Confirm 操作： 对业务系统做确认提交，确认执行业务操作，不做其他业务检查，只使用 Try 阶段预留的业务资源。
Cancel 操作： 在业务执行错误，需要回滚的状态下执行业务取消，释放预留资源。
TCC和2PC的区别：
XA是资源层面的分布式事务，强一致性，在两阶段提交的整个过程中，一直会持有资源的锁。基于数据库锁实现，需要数据库支持XA协议，由于在执行事务的全程都需要对相关数据加锁，一般高并发性能会比较差。
TCC是业务层面的分布式事务，最终一致性，不会一直持有资源的锁，性能较好。但是对微服务的侵入性强，微服务的每个事务都必须实现try、confirm、cancel等3个方法，开发成本高，今后维护改造的成本也高为了达到事务的一致性要求，try、confirm、cancel接口必须实现幂等性操作由于事务管理器要记录事务日志，必定会损耗一定的性能，并使得整个TCC事务时间拉长。