分布式事务的2PC、3PC、TCC

2PC（Two Phase Commit）

顾名思义，二阶段提交的意思。

1. 发起事务（Prepare）
   事务的发起者提出一个请求（比如下单购买某个商品），要求其依赖的服务响应请求（比如锁定优惠券，冻结库存等等）
   当所有的依赖方成都回复确认之后，事务的准备阶段完毕
2. 确认/取消事务（Confirm/Cncel）
   当请求得到所有的依赖服务的确认后，事务的发起者通知所有执行者确认(confirm)事务
   如果第一步只有有一个执行者返回失败，则取消（Cancel）事务

需要考虑的问题：

1. 执行者如果没有收到第二步事务，如何处理？此时执行者会一起锁定资源等待第二步事务
   比起一直锁定和超时confirm，更适合直接超时cancel
2. 发起者如果第一步没有收到回复，如何处理？此时发起者无法得知是否所有执行者都锁定资源
   超时重试，多次超时当作失败
3. 发起者如果第二步没有收到回复，如何处理？此时的发起者无法得知是否所有执行者都确认了事务
   这是一个无法回滚的异常，可能需要人工介入修复数据

3PC（Three Phase Commit）

2PC的改进版本，在Prepare阶段前加了一个阶段：是否可提交请求
询问是否可以执行事务提交操作，如果执行者都返回成功响应，则进入Prepare阶段，否则结束事务
这一步查询不会加锁，降低了反复“锁定-释放”的可能，提高了并发。

无论是2PC还是3PC，都无法彻底解决分布式的一致性问题。

TCC（Try-Confirm-Cancel）

TCC和2PC两阶段提交类似，2PC通常是跨库的DB层面，T本质上是一个应用层面的2PC。
优势在于，可以自己定义数据库操作的精度，从而降低锁冲突、提高吞吐量。
Try、Confirm、Cancel的缩写，又称补偿事务，要求每个分支事务实现这三个操作。
Try，对业务系统做检测及资源预留。和二阶段中提交协议，提交请求阶段类似，系统会将需要确认的资源预留、锁定，确保确认操作一定能执行成功
Confirm，确认执行业务操作。和二阶段提交协议中，提交执行阶段的操作类似，指系统将最终执行操作
Cancel，取消执行业务操作。比较像二阶段提交协议中的回滚操作，指系统将撤消之前预留的资源，也就是撤消已执行的预留操作对系统产生的影响