一、解决方案
① TCC补偿性事务
② saga、LCN
③ 基于MQ的事务异步确保型，需要业务系统结合MQ消息中间件实现，在实现过程中需要保证消息的成功发送及成功消费。即需要通过业务系统控制MQ的消息状态
④ 最大努力通知型，这种方案主要用在与第三方系统通讯时，比如：调用微信或支付宝支付后的支付结果通知，达到通知次数后即不再通知。
⑤ 2PC
⑥ 3PC
二、什么是TCC
TCC事务提交协议，全称是：try-confirm-cancel，也是一个分为两个阶段的事务提交协议
三、TCC事务提交协议
阶段一
主业务尝试（try）调用从业务，从业务并不直接执行，而是进行一个预留操作。比如，扣减库存问题，并不直接扣减库存，而是预留一个扣减字段，表示要扣减多少库存。阶段二
在从业务都返回yes的情况下，主业务将会确认（confirm）之前的预留操作，也就是会根据之前的扣减字段直接扣减库存了。那如果不是全部yes的情况下，就会调用取消（cancel）请求，取消之前的扣减字段。
四、TCC与2PC的区别
相同点
tcc和2pc都是两个阶段，一阶段并不真正的执行业务，二阶段根据一阶段的结果进行确认或者取消。所以，你会觉得在外观上两者似乎非常相似。不同点
开发者感知
tcc和2pc的本质区别就是tcc面向的是业务层面，2pc面向的是资源层面，什么意思？
我们在学习2pc的时候，我们总说一阶段是prepare事务，也就是不真正的提交事务。也就是说对资源的更新操作实际上并没有执行，记录在事务日志中准备二阶段的commit或者rollback。但是这些对于开发者来说其实是无感知的，开发者仍旧对资源进行单一的更新操作。
而tcc，它的一阶段进行try预留操作，也就是说开发者需要从业务层面来考虑这个问题，提供try-confirm-cancel这样的一个业务逻辑来为维护事务提交，开发者对此是感知得很明显的。我们也可以理解为对业务的入侵。
- 强一致性和最终一致性
2pc在一定程度上我们称之为强一致性，所以2pc的执行过程会独占资源，持有资源的互斥锁，这也是2pc效率比较低的原因。而tcc虽然增加了业务代码的复杂性，但是在业务层面上避免长时间占用资源，通过一种confirm或cancel的补偿机制来完成整个业务操作，也就是保持最终一致性。最终一致性并不需要长时间持有资源的锁，每一个事务其实都是相互独立的，所以tcc的效率会更高。
