java 分布式开发 事物管理_分布式事务的实现方式

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事务协调器协调，如果正常结束那就正常完成，如果某个步骤失败，则根据相反顺序一次调用补偿操作