分布式事务的实现方式

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