关注可以查看更多粉丝专享blog~

第一阶段：请求/表决阶段
- 在分布式事务发起者向分布式事务协调者发送请求的时候，事务协调者向所有参与者发送事务预处理请求（vote request）
- 这个时候参与者会开启本地事务并开始执行本地事务，执行完成后不会commit，而是向事务协调者报告是否可以处理本次事务
第二阶段：提交/执行/回滚阶段
- 分布式事务协调者收到所有参与者反馈后，所有参与者节点均响应可以提交，则通知参与者和发起者执行commit，否则rollback

三点常见问题：

性能问题：从流程上面可以看出，最大的缺点就是在执行过程中节点都处于阻塞状态。各个操作数据库的节点都占用着数据库资源，只有当所有节点准备完毕，事务协调者才会通知进行全局commit/rollback，参与者进行本地事务commit/rollback之后才会释放资源，对性能影响较大。
单点故障问题：事务协调者是整个分布式事务的核心，一旦事务协调者出现故障，会导致参与者收不到commit/rollback的通知，从而导致参与者节点一直处于事务无法完成的中间状态。
消息丢失问题：在第二阶段的时候，如果发生局部网络问题，一部分事务参与者收不到commit/rollback消息，那么就会导致节点间数据不一致。

在2PC的基础上增加了CanCommit阶段，并引入了超时机制。一旦事务参与者指定时间没有收到协调者的commit/rollback指令，就会自动本地commit，这样可以解决协调者单点故障的问题。

If, after a cohort member receives a preCommit message, the coordinator fails or times out, the cohort member goes forward with the commit.

Try
- 做业务检查及资源预留（比如冻结库存，而不是直接减库存）。
Confirm
- 确认提交，在Try阶段所有事务参与者执行成功之后开始执行Confirm，通常情况下，TCC默认Confirm是不会出错的，认为只要Try成功，则Confirm一定成功，若Confirm真的出错了，需要采用重试机制或者人工干预。
Cancel
- 执行回滚，在Try阶段有事务参与者执行失败则开始执行Cancel，通常情况下，TCC默认Cancel是不会出错的，认为只要Try成功，则Cancel一定成功，若Cancel真的出错了，需要采用重试机制或者人工干预。

优缺点：

RocketMQ事务消息流程图（图片来自阿里云）：

RocketMQ事务消息共有三种状态，提交状态、回滚状态和中间状态。

执行流程：

消息发送方开启事务，发送半事务消息到RocketMQ，但是该消息只保存在commitlog中，对消费者是不可见的，没有保存到customerQueue中。
消息发送方处理完本次事务之后，进入第二阶段。
1. 如果成功则发送commit确认消息到RocketMQ将半事务消息保存到customerQueue中，让customer进行消费。
2. 如果失败则发送rollback消息到RocketMQ将半事务消息删除。

异常分析：

消息回查机制：

保障消费幂等性：

强一致性分布式事务代码入侵较低，但是会阻塞，占用资源，影响性能；TCC代码和业务入侵较大；弱一致性事务异步操作就会涉及到异常情况下的回滚重试，回滚失败等。所以最后还是需要从自身业务情况触发来进行选择，以下是目前主流分布式事务实现（排名不分先后）。