可靠消息最终一致性

此方ζ案涉及 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 组件中。
• 下游应用监听消息，在满足幂等性的条件下，重新执行业务。
• 下游应≡用通知可靠消息服务该消息已经成功消费。

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