#分布式事务 dtf
微服务事务数据一致性服务
FMT 接入模式下是否支持操作没有主键的数据库？
已采纳
TCC 与 FMT 能否嵌套使用？
已采纳
在 TCC 事务下，可嵌套 TCC 与 FMT 子事务。
在 FMT 事务下，可嵌套 FMT 子事务，不可嵌套 TCC 子事务（暂时不支持，在后续支持其他类型子事务，如非 DB 操作的 FMT 子事务，也可能产生 FMT 下 TCC 事务的主子关系）。
在一个主事务中，TCC 与 FMT 子事务支持混用。... 展开详请
使用 Apache 的 Sharding JDBC 报错如何处理？
已采纳
DTF 的 FMT 模式暂时不兼容 Sharding JDBC，在 FMT 模式下会出现兼容性问题。如果您只需要使用 TCC 模式，可参考 开发文档 - 客户端配置，配置 dtf.env.fmt 为 false 以解决该问题。
DTF 如何与 TSF 协同使用？
在 TCC 模式中，Confirm 和 Cancel 可能和 Try 并行甚至在 Try 之前执行吗？
已采纳
可能出现。例如空回滚问题和悬挂问题。
空回滚问题描述：Try 未执行时，Cancel 执行。
空回滚问题解决方案：Cancel 操作判断一阶段是否已执行，识别空回滚后，直接返回成功；具体来讲：需要一张额外的事务控制表，其中有分布式事务 ID 和分支事务 ID，第一阶段 Try 方法里会插入一条记录，表示一阶段执行了。Cancel 接口里读取该记录，如果该记录存在，则正常回滚；如果该记录不存在，则是空回滚。
悬挂问题描述：Try 超时，执行 Cancel，Try 接口恢复。出现的原因是 Try 由于网络拥堵而超时，事务管理器生成回滚，触发 Cancel 接口，而最终又收到了 Try 接口调用，但是 Cancel 比 Try 先到。
悬挂问题解决方案：按照前面允许空回滚的逻辑，回滚会返回成功，事务管理器认为事务已回滚成功，则此时的 Try 接口不应该执行，否则会产生数据不一致，所以我们在 Cancel 空回滚返回成功之前先记录该条事务 xid 或业务主键，标识这条记录已经回滚过，Try 接口先检查这条事务xid或业务主键如果已经标记为回滚成功过，则不执行 Try 的业务操作。... 展开详请
在 TCC 模式中，是否需要考虑幂等？
已采纳
需要考虑幂等问题。
幂等问题的解决方案为：DTF 框架会在 Confirm 和 Cancel 执行后将事务状态改为已提交或已回滚状态，因此，重复调用在 Confirm 和 Cancel 接口时，先获取状态，如果已执行，直接返回成功。
如果调用链为 A->B->C，B.try 报错，A.cancel，B.cancel，C.cancel 哪些会执行？
已采纳
B 的 Try 报错，因此 C 的 Try 还未操作，因此事务协调器会发起对 A 与 B 的 Cancel。A 与 B 的 Cancel 无先后顺序。
总结：事务协调器发起 Confirm 与 Cancel 操作均无先后顺序，在 Try 成功/失败后，后续阶段的顺序本身无意义。无序执行能够带给您更高性能。... 展开详请
如果 Confirm 或者 Cancel 报错，重试机制是怎样的？
已采纳
会有三次重试。分为两种情况：
情况一：Confirm/Cancel 逻辑有误，TC 下发 Confirm/Cancel 请求5秒内客户端无响应，此时会立刻开始下一次重试。若三次重试请求下发5秒内客户端都无响应，则本条主事务状态变为异常事务。
情况二：闪断和节点故障导致的。即 TC 下发 Confirm/Cancel 请求后客户端有响应，则会等待15分钟。以下为每一次客户端都成功响应的兜底重试策略。
第一次 Confirm 或 Cancel（非重试），持续15分钟。若超时，在1秒后开始第一次重试，持续15分钟；若依然超时，等待2秒开始第二次重试，持续15分钟；若还是超时，等待3秒开始第三次重试15分钟。若依然失败，则转为异常事务。... 展开详请
如果 Try 超时了，框架是否会回滚 Try 的本地事务并阻止后续调用链？
已采纳
在事务协调器故障的情况下，事务的提交和回滚还能正常进行吗?
已采纳
DTF 是否支持私有化部署？
腾讯云开发者
