结果接口协议 #

当前页面介绍的结果口协议，适用于1.9.x及更低版本，如果您的dtm版本大于等于1.10.x，采用本协议不会出错，但是建议采用新的协议。升级指南参考升级指南

角色间通信协议 #

目前dtm只支持了http和grpc协议。由于分布式事务涉及多个角色协作，某些参与者可能出现暂时不可用，需要重试；某些参与者明确告知失败，需要进行回滚。

HTTP #

下面对各种情况进行分类说明，定义各类情况的返回值。接口类似微信/支付宝订单成功回调的接口:

• 如果接口返回的结果中，包含SUCCESS，则表示成功；
• 如果接口返回的结果中，包含FAILURE，则表示失败;
• 如果接口返回的结果中，包含ONGOING，则表示正常进行中，需要按照指定的时间间隔重试;
• 其他则表示出错，需要进行重试，重试时采用退避算法，避免雪崩。

上面的架构图中，主要有以下几类接口：

AP调用TM的接口，主要为全局事务注册、提交，子事务注册等： #

• 成功:
• 失败: { dtm_result: "FAILURE" }，表示这个请求状态不对，例如已经走fail的全局事务不允许再注册分支
• 其他表示状态不确定，可重试

TM调用RM的接口，主要为二阶段的提交、回滚，以及saga的各分支操作 #

• 成功:
• 失败: { dtm_result: "FAILURE" }，表示这个接口业务失败，全局事务需要进行回滚。例如saga中的正向操作如果返回FAILURE，则整个saga事务失败回滚
• 进行中: { dtm_result: "ONGOING" }，表示这个接口正常进行中，后续按照固定间隔重试
• 其他结果则重试，一直按照退避算法重试，直到返回上述的两个结果之一

AP调用RM的接口，跟业务相关，主要是被TCC、XA两种模式调用。 #

考虑到许多微服务的治理，都有失败重试的机制，因此建议接口设计（由于是AP和RM之间的接口，dtm不做强制要求）如下：

• 成功: { dtm_result: "SUCCESS" }。返回的结果可以额外包含其他业务数据。
• 失败: { dtm_result: "FAILURE" }，表示这个接口业务失败，全局事务需要进行回滚。例如tcc中的Try动作如果返回FAILURE，则整个tcc全局事务回滚
• 其他返回值，应当允许重试，重试如果还是失败，需要允许全局事务回滚。主要是因为TCC、XA事务的下一步操作不保存在数据库，而是在AP里，它需要及时响应用户，无法长时间等待故障恢复。

GRPC #

由于GRPC为强类型协议，并且定义好了各个错误状态码，并且能够定义不同的错误码，采用不同的重试策略，因此GRPC的协议如下：

GRPC协议 #

• 成功: OK。对应上述http协议中的
• 失败: Aborted && Message=="FAILURE"。对应上述http协议中的{ dtm_result: "FAILURE" }，表示失败;
• 进行中: Aborted && Message=="ONGOING"。对应上述http协议中的{ dtm_result: "FAILURE" }，则表示正常进行中，需要按照指定的时间间隔重试;
• 其他错误吗：状态未知，可重试，重试时采用退避算法，避免雪崩。

AP调用TM的接口，主要为全局事务注册、提交，子事务注册等： #

• nil：成功
• Aborted：表示这个请求状态不对，例如已经走fail的全局事务不允许再注册分支
• 其他错误：表示状态未知，可重试

type DtmServer interface {
  ...
  Submit(context.Context, *DtmRequest) (*emptypb.Empty, error)
}

TM调用RM的接口，主要为二阶段的提交、回滚，以及saga的各分支操作 #

• nil：成功
• Aborted && Message=="FAILURE"：表示失败，需要回滚事务
• Aborted && Message=="ONGOING"：表示进行中，后续采用固定间隔重试
• 其他错误：表示出错，采用退避算法重试

AP调用RM的接口，跟业务相关，主要是被TCC、XA两种模式调用。返回的结果 #

• 这部分接口用户完全自定义，dtm并不关心。建议用户采用“TM调用RM的接口”相同的设计，保持统一

重试策略 #

失败重试是微服务治理中，很重要的一个环节，上述http和grpc协议，能够很好的与主流的失败重试策略兼容

当全局事务由于某些组件导致临时故障，那么全局事务会暂时中断，后续dtm会定时轮询未完成的全局事务，进行重试。一般多次重试则间隔每次加倍，避免雪崩。

许多事务模式中的操作是要求不允许失败/最终成功的，含义见最终成功