FMT 模式
最近更新时间: 2024-10-17 17:10:00
概述
FMT（Framework-managed Transaction）模式下，DTF 通过框架解析您的 SQL 语句，免去了编写 Confirm/Cancel 方法的烦恼，接入使用便捷，对代码无侵入，助您高效完成业务分布式事务的开发。 FMT 模式与 TCC 模式的事务协调器 TC 并无差异，仅在 RM 操作层面与 TCC 产生差异。
FMT 执行流程
FMT 框架会代理数据驱动层，执行流程如下：
执行正常逻辑时，可以理解为 Try 阶段。框架解析 SQL 语句，生成 SELELCT 语句和 UNDO 语句模板，等待全局锁，然后在同一个本地事务中：注册分支事务、查询前象、执行 SQL、查询后象、记录 UNDO LOG。如果过程中出现异常，则会释放全局锁，否则会等待分支事务提交/回滚时再释放全局锁。
Confirm 过程相对简单，删除 UNDO LOG 并释放全局锁即可。
Cancel 过程稍微复杂，先要检查当前数据是否符合 Try 中查询的后象，然后执行 UNDO 语句，再检查数据是否符合 Try 中查询的前象，最后删除 UNDO LOG 并释放全局锁。 如果出现前象或者后象不一致时，回滚本地事务，不释放全局锁，等待人工介入（异常事务）。
DTF 的 FMT 优势
支持可重入锁
相比目前友商的 FMT 模式或类似模式，DTF 能够处理更复杂的应用场景：可重入锁。
- 举例如下：在一条主事务中，多个分支事务对数据表中某一行数据进行了多次操作：增（create）、改（update 可能多次）、删（delete），此时会涉及到可重入锁的问题。
- 实际场景：在一次交易中，新增了一条订单数据，而本次交易又涉及到其他操作（其他分支事务），需要修改本条订单数据。这种场景下，如果需要回主事务，会涉及到按倒序回滚改操作、增操作，即反向执行可重入锁。
为了保证事务一致性，FMT 会在业务操作某一行数据时进行锁行，在重入锁的场景下，会涉及到生成多次行锁。目前友商的同类型模式，不支持处理重入锁场景的回滚操作。DTF 的 FMT 模式支持可重入锁，助您在配置简单的 FMT 接入模式下实现更广阔的业务需求。