分布式协议与算法实战——ACID理论（笔记）

分布式系统涉及多个节点间的操作。加锁、时间序列等机制，只能保证单个节点上操作的 ACID特性，无法保证节点间操作的 ACID 特性。在分布式系统中需要使用分布式事务协议，比如二阶段提交协议和TCC（Try-Confirm-Cancel）

二阶段提交协议

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

具体实现流程

（1）客户端向节点1发送请求，节点1接收到消息后就扮演协调者的身份，由节点1联系其他节点，发起二阶段提交；
（2）节点1发起二阶段提交后，进入提交请求阶段（又称投票阶段）；

• 首先节点1分别想其他节点发送消息
• 其他节点分别评估是否能够执行事务，如果能就预留时间并锁定，不再安排其他事务；
• 节点1得到全部的回复结果（包括自己的评估结果）如果都是YES；
  （3）节点1收到所有回复后，进入提交执行阶段（又称完成阶段）
• 节点1按照“要么全部执行，要么放弃的原则，统计投票结果，因为所有的回复结果都是 YES，所以节点1决定执行分布式事务；
• 节点1通知其他节点，执行事务；
• 接到通知之后，其他节点执行事务
• 其他节点将执行事务的结果返回给节点1
• 节点1将事务执行的结果，返回给客户端，这是客户端就解决了问题。

总结

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

在第二个阶段，事务的每个参与者执行最终统一的决定，提交事务或者放弃事务。这个约定，是为了实现 ACID 中的原子性。

TCC（Try-Confirm-Cancel）

TCC 是 Try（预留）、Confirm（确认）、Cancel（撤销） 3 个操作的简称，它包含了预留、确认或撤销这 2 个阶段。

TCC协议执行流程

（1）进入到预留阶段

• 客户端分别发送效益通知所有节点，让节点预留时间和其他相关资源。然后客户端实现确认操作和撤销操作；
• 客户端收到节点的预留答复，都是OK；

（2）如果预留阶段的执行都没有问题，就进入确认阶段

• 客户端执行确认操作，通知节点执行事务
• 收到确认操作的响应，完成分布式事务

（3）如果预留阶段执行出错，那么就进入撤销阶段

• 客户端执行撤销操作，通知所有节点取消执行事务；
• 收到撤销操作的响应

总结

TCC 本质上是补偿事务，它的核心思想是针对每个操作都要注册一个与其对应的确认操作和补偿操作（也就是撤销操作）。

它是一个业务层面的协议，你也可以将TCC 理解为编程模型，TCC 的 3 个操作是需要在业务代码中编码实现的，为了实现一致性，确认操作和补偿操作必须是等幂的，因为这 2 个操作可能会失败重试。

TCC 不依赖于数据库的事务，而是在业务中实现了分布式事务，这样能减轻数据库的压力，但对业务代码的入侵性也更强，实现的复杂度也更高。所以，推荐在需要分布式事务能力时，优先考虑现成的事务型数据库（比如 MySQL XA），当现有的事务型数据库不能满足业务的需求时，再考虑基于 TCC 实现分布式事务。