1.两阶段提交（2PC）

2pc：两阶段提交算法，需要保证任何一个资源都成功，整个分布式事务才成功；

它本身是一致强一致性算法，所以很适合用作数据库的分布式事务。其实数据库的经常用到的 TCC 本身就是一种 2PC。

• undo 和 redo
  对一条数据的修改操作首先写 undo 日志，记录的数据原来的样子，接下来执行事务修改操作，把数据写到 redo 日志里面，如果事务失败了，可从 undo 里面回复数据。

  
  image.png

1.1 优点：

操作简单

1.2 缺点：

• 同步阻塞：
  在二阶段提交的过程中，所有的节点都在等待其他节点的响应，无法进行其他操作。这种同步阻塞极大的限制了分布式系统的性能。
• 单点问题：
  协调者在整个二阶段提交过程中很重要，如果协调者在提交阶段出现问题，那么整个流程将无法运转。更重要的是，其他参与者将会处于一直锁定事务资源的状态中，而无法继续完成事务操作。
• 数据不一致：
  假设当协调者向所有的参与者发送 commit 请求之后，发生了局部网络异常，或者是协调者在尚未发送完所有 commit 请求之前自身发生了崩溃，导致最终只有部分参与者收到了commit 请求。这将导致严重的数据不一致问题。
• 容错性不好：
  二阶段提交协议没有设计较为完善的容错机制，任意一个节点是失败都会导致整个事务的失败。

2.三阶段提交（3pc）

由于二阶段提交存在着诸如同步阻塞、单点问题，所以，研究者们在二阶段提交的基础上做了改进，提出了三阶段提交

image.png

2.1 第一阶段 canCommit

确认所有的资源是否都是健康、在线的，以约女孩举例，你会打个电话问下她是不是在家，而且可以约个会。

就因为有了这一阶段，大大的减少了 2 段提交的阻塞时间，在 2 段提交，如果有 3 个数据库, 恰恰第三个数据库出现问题，其他两个都会执行耗费时间的事务操作，到第三个却发现连接 不上。3 段优化了这种情况

2.2 第二阶段 PreCommit

如果所有服务都 ok，可以接收事务请求，这一阶段就可以执行事务了，这时候也是每个资源都回写 redo 与 undo 日志，事务执行成功，返回 ack(yes),否则返回 no

2.3 第三阶段 doCommit

这阶段和前面说的 2 阶段提交大同小异，这个时候协调者发现所有提交者事务提交者事务都正常执行后，给所有资源发送 commit 指令。

和二阶段提交有所不同的是，他要求所有事务在协调者出现问题，没给资源发送 commit 指令的时候，三阶段提交算法要求资源在一段时间超时后回默认提交做 commit 操作
这样的要求就减少了前面说的单点故障，万一事务管理器出现问题，事务也回提交。
但回顾整个过程，不管是 2pc,还是 3pc，同步阻塞，单点故障，容错机制不完善这些问题都 没本质上得到解决，尤其是前面说得数据一致性问题，反而更糟糕了。
所有数据库的分布式事务一般都是二阶段提交，而者三阶段的思想更多的被借鉴扩散成其他 的算法。

2.4 和2pc对比

• 第二阶段才写undo和redo事物日志
• 第三阶段协调者出现异常或者网络超时参与者也会commit

2.5 优点

• 改善同步阻塞
• 改善单点故障

2.6 缺点

• 同步阻塞
• 单点故障
• 数据不一致
• 容错性不好

3.Paxos

image.png
核心：少数服从多数
协议要求:
1.如果接收者没有收到过提案编号，他必须接受第一个提案编号
2.如果接收者没有收到过其他协议，他必须接受第一个协议

3.1 第一阶段

少数服从多数后，进行下一阶段

3.2 第二阶段