目录
- 二阶段提交协议
- TCC（Try-Confirm-Cancel）
- 预留成功
- 预留失败
- 三阶段提交协议
- 总结
- Some questions
- reference
ACID理论时对事务特性的抽象和总结，想要实现ACID需要掌握二阶段提交协议以及TCC
这里是有关协议的论文PDF链接：
CONCURRENCY CONTROLAND RECOVERY IN DATABASE
SYSTEMS
二阶段提交协议
二阶段提交协议：通过二阶段的协商来完成一个提交操作
首先定义一个分布式事务操作，发起这个事务到分布式系统种的节点中。某一个节点收到消息后扮演协调者身份，与其他节点联系，发送网络消息，发起二阶段提交。
然后协调者进入请求提交阶段（即投票阶段），其他节点进行评估，评估事务中需要操作的对象和对象状态是否准备好、是否提交新操作，然后回复协调者，
协调者收到所有回复后，进入提交执行阶段（即完成阶段）。协调者先执行事务，然后通知其他节点，其他节点接收到通知后也执行事务，然后将事务结果返回给协调者。
协调者将总结果返回给客户。
需要注意的是：
在第一阶段，每个参与者投票表决事务是放弃还是提交。一旦参与者投票要求提交事务，那么就不允许放弃事务。即：
在一个参与者投票要求提交事务之前，它必须保证能够执行提交协议中它自己的那一部分，即使参与者出现故障或者中途被替换。
不过二阶段协议也存在问题：
1、在提交请求阶段，需要预留资源，在资源预留期间，其他人不能操作（MySQL XA协议在第一阶段会将相关资源锁定）
2、数据库是独立的系统
所以无法根据业务特点弹性调整锁的粒度，会影响到数据库的并发性能。
TCC（Try-Confirm-Cancel）
TCC是预留、确认、撤销三个操作的简称，包含了预留、确认or撤销两个阶段。
预留成功
进入预留阶段，步骤如下：
如果预留阶段的执行都没有问题，就进入确认阶段，步骤如下：
预留失败
假设节点2分配资源失败了：
那么会进入撤销阶段：
TCC本质：补偿事务
它的核心思想是针对每个操作都要注册一个与其对应的确认操作和补偿操作（也可以称为撤销操作）。
它是一个业务层面的协议，TCC的三个操作需要在业务代码中编码实现。为了实现一致性，确认操作和补偿操作必须是幂等的，因为这2个操作可能会失败重试。
Tips：幂等性是指同一操作对同一系统的任意多次执行，所产生的影响均与一次执行的影响相同，不会因为多次执行而产生副作用。常见的实现方法有Token、索引等。本质是通过唯一标识，标记同一操作的方式来消除多次执行的副作用。
三阶段提交协议
三阶段提交协议，针对二阶段提交协议的痛点：协调者故障，参与者长期锁定资源，引入了询问阶段和超市机制，来减少资源被长时间锁定的情况，但是会导致集群各个节点在正常运行的情况下，使用更多的消息进行协商，增加系统负载和响应延迟。所以三阶段提交协议很少使用。
总结
Some questions
在两阶段提交协议中，如果一个节点在第一阶段确认可以提交，但是它之后崩溃了，第二阶段无法实现自己那部分事务，此时该如何是好？
需要将提交的相关信息持久化到磁盘，然后重启，恢复到之前状态
reference
ACID理论：CAP的酸，追求一致性
