持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第14天，点击查看活动详情
每日英语:
Personality is to man what perfume is to a flower.
翻译：人品之于人，犹如芳香之于花。 ——查尔斯·迈克尔·施瓦布
TCC
TCC与2PC、3PC一样，也是分布式事务的一种实现方案。TCC（Try-Confirm-Cancel）又称补偿事务。其核心思想是："针对每个操作都要注册一个与其对应的确认和补偿（撤销操作）"。它分为三个操作：
- Try阶段：主要是对业务系统做检测及资源预留。
- Confirm阶段：确认执行业务操作。
- Cancel阶段：取消执行业务操作。
TCC事务的处理流程与2PC两阶段提交类似，不过2PC通常都是在跨库的DB层面，而TCC本质上就是一个应用层面的2PC，需要通过业务逻辑来实现。这种分布式事务的实现方式的优势在于，可以让应用自己定义数据库操作的粒度，使得降低锁冲突、提高吞吐量成为可能。
不足之处则在于对应用的侵入性非常强，业务逻辑的每个分支都需要实现try、confirm、cancel三个操作。此外，其实现难度也比较大，需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。为了满足一致性的要求，confirm和cancel接口还必须实现幂等。
MQ分布式事务
在OLTP系统领域，我们在很多业务场景下都会面临事务一致性方面的需求，而大型互联网平台往往是由一系列分布式系统构成的，开发语言平台和技术栈也相对比较杂，尤其是在SOA和微服务架构盛行的今天，一个看起来简单的功能，内部可能需要调用多个“服务”并操作多个数据库或分片来实现，情况往往会复杂很多，如果对数据一致性要求很高，可以采用上一篇提到的2PC或者3PC以及本篇提到的TCC方案，如果数据强一致性要求没那么高，可以采用消息中间件（MQ）实现事务最终一致。
在支付系统中，常常使用的分布式事务解决方案就是基于MQ实现的，它对数据强一致性要求没那么高，但要求数据最终一致即可。例如：向借呗申请借钱，借呗审核通过后支付宝的余额才会增加，但借呗和支付宝有可能不是同一个系统，这时候如何实现事务呢？实现方案如下图：
上图执行流程：
1:找花呗借钱
2:花呗借钱审核通过，同步生成借款单
3:借款单生成后，向MQ发送消息，通知支付宝转账
4:支付宝读取MQ消息，并增加账户余额
上图最复杂的其实是如何保障2、3在同一个事务中执行（本地事务和MQ消息发送在同一个事务执行），借款结束后，借呗数据处理就完成了，接下来支付宝才能读到消息，然后执行余额增加，这才完成整个操作。如果中途操作发生异常，例如支付宝余额增加发生问题怎么办？此时需要人工解决，没有特别好的办法，但这种事故概率极低。
总结
本篇主要介绍了一下常用分布式事务解决方案中的TCC模式和MQ分布式事务处理方案，大家可以细细品味一下~
