分布式事务解决方案

解决方案是自研框架，不是阿里巴巴seata；
解决方案是自研框架，不是阿里巴巴seata；
解决方案是自研框架，不是阿里巴巴seata；

• IBPS V3分布式事务方案支持 TCC 、可靠消息最终一致性。
• 可以混合使用，即通用业务使用可靠消息最终一致性，强一致要求的场景下视同TCC方案。

TCC

TCC是三个首字母，Try-Confirm-Cancel，具体描述是将整个操作分为上面这三步。
两个微服务间同时进行Try，在Try的阶段会进行数据的校验，检查，资源的预创建，如果都成功就会分别进行Confirm，如果两者都成功则整个TCC事务完成。
如果Confirm时有一个服务有问题，则会转向Cancel，相当于进行Confirm的逆向操作。

可靠消息最终一致性

此方案涉及 3 个模块：

• 上游应用，执行业务并发送 MQ 消息。
• 可靠消息服务和 MQ 消息组件，协调上下游消息的传递，并确保上下游数据的一致性。
• 下游应用，监听 MQ 的消息并执行自身业务。

第一阶段：上游应用执行业务并发送 MQ 消息

上游应用将本地业务执行和消息发送绑定在同一个本地事务中，保证要么本地操作成功并发送 MQ 消息，要么两步操作都失败并回滚。

上游应用和可靠消息之间的业务交互图如下：

• 上游应用发送待确认消息到可靠消息系统。

• 可靠消息系统保存待确认消息并返回。

• 上游应用执行本地业务。

• 上游应用通知可靠消息系统确认业务已执行并发送消息。

• 可靠消息系统修改消息状态为发送状态并将消息投递到 MQ 中间件。

  以上每一步都可能出现失败情况，分析一下这 5 步出现异常后上游业务和消息发送是否一致：

上游应用执行完成，下游应用尚未执行或执行失败时，此事务即处于 BASE 理论的 Soft State 状态。

第二阶段：下游应用监听 MQ 消息并执行业务

下游应用监听 MQ 消息并执行业务，并且将消息的消费结果通知可靠消息服务。

可靠消息的状态需要和下游应用的业务执行保持一致，可靠消息状态不是已完成时，确保下游应用未执行，可靠消息状态是已完成时，确保下游应用已执行。
下游应用和可靠消息服务之间的交互图如下：

• 下游应用监听 MQ 消息组件并获取消息。

• 下游应用根据 MQ 消息体信息处理本地业务。

• 下游应用向 MQ 组件自动发送 ACK 确认消息被消费。

• 下游应用通知可靠消息系统消息被成功消费，可靠消息将该消息状态更改为已完成。

  以上每一步都可能出现失败情况，分析一下这 4 步出现异常后下游业务和消息状态是否一致：

通过分析以上两个阶段可能失败的情况，为了确保上下游数据的最终一致性，在可靠消息系统中，
需要开发 消息状态确认 和 消息重发 两个功能以实现 BASE 理论的 Eventually Consistent 特性。

消息状态确认和消息重发

异常处理一：消息状态确认

可靠消息服务定时监听消息的状态，如果存在状态为待确认并且超时的消息，则表示上游应用和可靠消息交互中的步骤 4 或者 5 出现异常。
可靠消息则携带消息体内的信息向上游应用发起请求查询该业务是否已执行。
上游应用提供一个可查询接口供可靠消息追溯业务执行状态，如果业务执行成功则更改消息状态为已发送，否则删除此消息确保数据一致。

具体流程如下：

• 可靠消息查询超时的待确认状态的消息。
• 向上游应用查询业务执行的情况。
• 业务未执行，则删除该消息，保证业务和可靠消息服务的一致性。业务已执行，则修改消息状态为已发送，并发送消息到 MQ 组件。

异常处理二：消息重发

消息已发送则表示上游应用已经执行，接下来则确保下游应用也能正常执行。

可靠消息服务发现可靠消息服务中存在消息状态为已发送并且超时的消息，则表示可靠消息服务和下游应用中存在异常的步骤，
无论哪个步骤出现异常，可靠消息服务都将此消息重新投递到 MQ 组件中供下游应用监听。

下游应用监听到此消息后，在保证幂等性的情况下重新执行业务并通知可靠消息服务此消息已经成功消费，
最终确保上游应用、下游应用的数据最终一致性。具体流程如下：

• 可靠消息服务定时查询状态为已发送并超时的消息。
• 可靠消息将消息重新投递到 MQ 组件中。
• 下游应用监听消息，在满足幂等性的条件下，重新执行业务。
• 下游应用通知可靠消息服务该消息已经成功消费。

通过消息状态确认和消息重发两个功能，可以确保上游应用、可靠消息服务和下游应用数据的最终一致性