分布式事务说的的2PC、3PC、TCC是啥
2PC(Two Phase Commit)
顾名思义,二阶段提交的意思。
- 发起事务(Prepare)
事务的发起者提出一个请求(比如下单购买某个商品),要求其依赖的服务响应请求(比如锁定优惠券,冻结库存等等)
当所有的依赖方成都回复确认之后,事务的准备阶段完毕 - 确认/取消事务(Confirm/Cncel)
当请求得到所有的依赖服务的确认后,事务的发起者通知所有执行者确认(confirm)事务
如果第一步只有有一个执行者返回失败,则取消(Cancel)事务
需要考虑的问题:
- 执行者如果没有收到第二步事务,如何处理?此时执行者会一起锁定资源等待第二步事务
比起一直锁定和超时confirm,更适合直接超时cancel - 发起者如果第一步没有收到回复,如何处理?此时发起者无法得知是否所有执行者都锁定资源
超时重试,多次超时当作失败 - 发起者如果第二步没有收到回复,如何处理?此时的发起者无法得知是否所有执行者都确认了事务
这是一个无法回滚的异常,可能需要人工介入修复数据
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,取消执行业务操作。比较像二阶段提交协议中的回滚操作,指系统将撤消之前预留的资源,也就是撤消已执行的预留操作对系统产生的影响