分布式事务解决方案下

概要

个人理解: 柔性事务可以说是伪事务,柔性事务其实是根据不同的业务场景在业务层使用不同的方法(2pc,事后补偿,消息队列)实现最终一致性

理解: 采取事件机制和消息队列实现分布式事务,来确保消息的最终一致性

分布式事务解决方案下 - 图1

分布式事务解决方案下 - 图2

理解: 业务主动方完成业务后向业务被动方发送业务通知,允许消息发送失败,当消息发送失败时会按规制重发N次,如果N次后还未收到业务被动方回复则不在发送消息,业务主动方会提供可查询接口供业务被动方查询

分布式事务解决方案下 - 图3

行业示例: 银行通知,商户通知

理解: TCC实际是将一个整体事务拆分为一个个小事务(本地事务),每个事务见互不干扰

主业务服务：主业务服务为整个业务活动的发起方。
从业务服务：从业务服务负责提供TCC业务操作，是整个业务活动的操作方。从业务服务必须实现Try、Confirm和Cancel三个接口，供主业务服务调用。
业务活动管理器(框架内部)：业务活动管理器管理控制整个业务活动，包括记录维护TCC全局事务的事务状态和每个从业务服务的子事务状态，并在业务活动提交时确认所有的TCC型操作的confirm操作，在业务活动取消时调用所有TCC型操作的cancel操作。

TCC事务的优点:
- 解决了跨应用业务操作的原子性问题，在诸如组合支付、账务拆分场景非常实用。
- TCC实际上把数据库层的二阶段提交上提到了应用层来实现，对于数据库来说是一阶段提交，规避了数据库层的2PC性能低下问题。
TCC事务的缺点
- TCC的Try、Confirm和Cancel操作功能需业务提供，开发成本高。

Try：尝试执行业务。
完成所有业务检查(一致性)：检查A、B、C的帐户状态是否正常，帐户A的余额是否不少于30元，帐户B的余额是否不少于50元。预留必须业务资源(准隔离性)：帐户A的冻结金额增加30元，帐户B的冻结金额增加50元，这样就保证不会出现其他并发进程扣减了这两个帐户的余额而导致在后续的真正转帐操作过程中，帐户A和B的可用余额不够的情况。
Confirm：确认执行业务。
真正执行业务：如果Try阶段帐户A、B、C状态正常，且帐户A、B余额够用，则执行帐户A给账户C转账30元、帐户B给账户C转账50元的转帐操作。不做任何业务检查：这时已经不需要做业务检查，Try阶段已经完成了业务检查。只使用Try阶段预留的业务资源：只需要使用Try阶段帐户A和帐户B冻结的金额即可。
Cancel：取消执行业务
释放Try阶段预留的业务资源：如果Try阶段部分成功，比如帐户A的余额够用，且冻结相应金额成功，帐户B的余额不够而冻结失败，则需要对帐户A做Cancel操作，将帐户A被冻结的金额解冻掉。

柔性事务解决方案概述