二阶段提交协议

二阶段提交协议：通过二阶段的协商来完成一个提交操作

首先定义一个分布式事务操作，发起这个事务到分布式系统种的节点中。某一个节点收到消息后扮演协调者身份，与其他节点联系，发送网络消息，发起二阶段提交。
然后协调者进入请求提交阶段（即投票阶段），其他节点进行评估，评估事务中需要操作的对象和对象状态是否准备好、是否提交新操作，然后回复协调者，
协调者收到所有回复后，进入提交执行阶段（即完成阶段）。协调者先执行事务，然后通知其他节点，其他节点接收到通知后也执行事务，然后将事务结果返回给协调者。
协调者将总结果返回给客户。

需要注意的是：
在第一阶段，每个参与者投票表决事务是放弃还是提交。一旦参与者投票要求提交事务，那么就不允许放弃事务。即：
在一个参与者投票要求提交事务之前，它必须保证能够执行提交协议中它自己的那一部分，即使参与者出现故障或者中途被替换。

不过二阶段协议也存在问题：
1、在提交请求阶段，需要预留资源，在资源预留期间，其他人不能操作（MySQL XA协议在第一阶段会将相关资源锁定）
2、数据库是独立的系统

所以无法根据业务特点弹性调整锁的粒度，会影响到数据库的并发性能。

TCC（Try-Confirm-Cancel）

TCC是预留、确认、撤销三个操作的简称，包含了预留、确认or撤销两个阶段。

预留成功

进入预留阶段，步骤如下：
在这里插入图片描述

如果预留阶段的执行都没有问题，就进入确认阶段，步骤如下：
在这里插入图片描述

预留失败

假设节点2分配资源失败了：
在这里插入图片描述
那么会进入撤销阶段：

TCC本质：补偿事务
它的核心思想是针对每个操作都要注册一个与其对应的确认操作和补偿操作（也可以称为撤销操作）。
它是一个业务层面的协议，TCC的三个操作需要在业务代码中编码实现。为了实现一致性，确认操作和补偿操作必须是幂等的，因为这2个操作可能会失败重试。
Tips：幂等性是指同一操作对同一系统的任意多次执行，所产生的影响均与一次执行的影响相同，不会因为多次执行而产生副作用。常见的实现方法有Token、索引等。本质是通过唯一标识，标记同一操作的方式来消除多次执行的副作用。