分布式事务
目录
1. TCC
TCC将事务提交分为Try - Confirm - Cancel3个操作
Try：预留业务资源、数据校验
Confirm：确认执行业务操作
Cancel：取消执行业务操作
TCC事务处理流程和2PC二阶段提交类型，不过2PC通常都是在跨库DB层面，而TCC本质就是一个应用层面的2PC.
TCC优缺点
- 优点
让应用自己定义数据库操作的粒度，使得降低锁冲突、提高吞吐量成为可能。
- 缺点
1) 对应用的侵入性强。业务逻辑的每个分支都需要实现Try、Confirm、Cancel三个操作
2) 实现难度大，需要按照网络状态、系统故障等不同的失败原理实现不同的回滚策略，为满足一致性的要求，Confirm和Cancel必须实现幂等
TCC应用场景
2. 本地消息表
基本思路
-
消息生产方，需要额外建一个消息表，并记录消息发送状态。消息表和业务数据要在一个事务里提交，也就是说他们要在一个数据库里面。然后消息会经过MQ发送到消息的消费方。如果消息发送失败，会进行重试发送。
-
消息消费方，需要处理这个消息，并完成自己的业务逻辑。此时如果本地事务处理成功，表明已经处理成功了，如果处理失败，那么就会重试执行。如果是业务上面的失败，可以给生产方发送一个业务补偿消息，通知生产方进行回滚等操作。
-
生产方和消费方定时扫描本地消息表，把还没处理完成的消息或者失败的消息再发送一遍。
3. 事务消息
事务消息作为一种异步确保型事务， 将两个事务分支通过MQ进行异步解耦，事务消息的设计流程同样借鉴了两阶段提交理论，整体交互流程如下图所示：
基本思路
-
事务发起方首先发送prepare消息到MQ。
-
在发送prepare消息成功后执行本地事务。
-
根据本地事务执行结果返回commit或者是rollback。
-
如果消息是rollback，MQ将删除该prepare消息不进行下发，如果是commit消息，MQ将会把这个消息发送给consumer端。
-
如果执行本地事务过程中，执行端挂掉，或者超时，MQ将会不停的询问其同组的其它producer来获取状态。
-
Consumer端的消费成功机制有MQ保证。