TCC
参与角色
业务活动管理器（协调者）、业务服务
TCC解释
Try阶段：尝试执行,完成所有业务检查（一致性）,预留必须业务资源（准隔离性）
Confirm阶段：确认执行真正执行业务，不作任何业务检查，只使用Try阶段预留的业务资源，Confirm操作满足幂等性。要求具备幂等设计，Confirm失败后需要进行重试。
Cancel阶段：取消执行，释放Try阶段预留的业务资源 Cancel操作满足幂等性Cancel阶段的异常和Confirm阶段异常处理方案基本上一致。
实现
PS：所有业务需要实现TCC接口；通过补偿可以实现最终一致性。
实例
举个简单的例子如果你用100元买了一瓶水， Try阶段:你需要向你的钱包检查是否够100元并锁住这100元，水也是一样的。如果有一个失败，则进行cancel(释放这100元和这一瓶水)，如果cancel失败不论什么失败都进行重试cancel，所以需要保持幂等。如果都成功，则进行confirm,确认这100元扣，和这一瓶水被卖，如果confirm失败无论什么失败则重试(会依靠活动日志进行重试)
数据库分布式事务中的 XA Transactions
角色
事务管理器（协调者）、业务服务
实现
第一阶段：事务管理器要求每个涉及到事务的数据库预提交(precommit)此操作，并反映是否可以提交.
第二阶段：事务协调器要求每个数据库提交数据，或者回滚数据。
PS： XA协议基于2pc协议实现。
MQ
角色
消息中间件、业务服务
实现
第一阶段Prepared消息，会拿到消息的地址。
执行本地事务。
第二阶段确认消息发送，如果确认消息失败，在RocketMq Broker中提供了定时扫描没有更新状态的消息，如果有消息没有得到确认，会向消息发送者发送消息，来判断是否提交
第三阶段中间件发送消息给其它业务服务。如果 发送超时，则需要一直发送。
第四阶段其它业务服务处理完成之后，需要通过中间件反馈给发起者。如果处理失败，则需要人工处理（由人工决定是否回滚或者继续）。
SAGA
角色
协调器、业务服务
实现
由Saga事务协调器协调，如果正常结束那就正常完成，如果某个步骤失败，则根据相反顺序一次调用补偿操作