CAP理论

分布式肯定是绕不过CAP理论的，也就是在一个分布式系统中，一致性，可用性，分区容忍性三者不可兼得。

一致性：分布式的所有数据备份，在任意时刻的数据是否相同

可用性：分布式系统，一个节点故障，其余节点是否能继续提供服务

分区容忍性：系统在遇到网络分区的的情况下，依然能够正常运行。也就是说，分布式系统当网络故障，一部分系统不能和其余系统通信时，仍然能正常运行。

2PC

解决分布式事务，最简单的方式就是2PC，也就是两阶段提交。

两阶段包括：

1. 准备阶段
   XA协调者向事务参与者发送准备请求，参与者执行事务并且返回事务的执行结果。
   虽说是准备阶段，实际已经开始执行事务操作并反馈结果了。
2. 提交阶段 等待所有的参与者反馈完成对准备阶段的结果，如果全部成功则XA协调者同步所有的参与者提交；如果任何一个事务失败，则通知全部的参与者回滚。

用的比较多的就是数据库的binlog和redolog的一致性保证。

写redo log和bin log实际上是两个部分执行的，一个是InnoDB的引擎，另一个则是Server。所以可能存在两者不一致的情况。

所以就需要通过协调事务XA来执行准备阶段，当双方都执行完完成之后，XA事务会协调commit

值的一题的是，2PC全程会保持锁的持有，直到commit，所以会阻塞其余同类修改。

3PC

2PC直接就要求参与者执行事务，而不是询问参与者的执行能力，所以可能会导致资源的浪费，所以出现了3PC

3PC在2PC的任务执行前增加了确认事务是否能执行的判断，如果不能执行，直接不开启事务。

TCC

其实本质上是与2PC相似的，但是2PC整个分布式事务期间，都会占据资源的锁，会阻塞其余事务。

但是TCC本质上则是在业务层进行补偿，而不是在事务层进行回滚。

TCC分为三个部分：

Try：预留事务资源，但是实际不执行事务，Try后会释放锁。

Confirm：如果所有资源都预留成功，则实际按照预留方式执行事务，这里需要假设Confrim是一定会成功的。

Cancel：如果存在资源预留失败，则对之前的预留进行取消，执行补偿。

SAGA

最大的特色就是将一系列事务拆成多个本地事务，对于每个本地事务有一个独特的补偿事务。