最大努力通知方案是什么？和其他分布式事务方案有何不同？

简化版

最大努力通知是一种对一致性要求较低的柔性事务方案：发起方尽「最大努力」（通过多次、逐渐拉长间隔的重试）去通知接收方处理结果，但不保证一定送达；同时提供一个查询接口让接收方主动来核对，兜住通知没收到的情况。它的典型场景是跨系统、跨企业的结果通知——比如支付平台通知商户「支付成功」，支付宝的异步回调就是这种模式。

详细版

核心特征：

• 发起方尽力通知：通知失败就按递增间隔重试（如 1min、5min、10min、30min、1h…），试到成功或达到最大次数为止。
• 允许通知失败：即使重试完还没成功，也不强求——因为提供了兜底的查询接口。
• 接收方提供查询接口 + 主动核对：接收方可以主动来查「这笔到底成没成」（对账），弥补通知丢失。
• 接收方幂等：同一通知可能被重复送达，处理要幂等。

和其他方案的区别：

• 一致性要求：最大努力通知 < 本地消息表/事务消息 < TCC/Saga < 2PC。它是最弱的一档，靠「重试 + 主动查询/对账」达到最终一致。
• 适用边界：常用于跨系统、跨企业、网络不可控的通知（支付回调、账单同步），系统间没法用统一的事务框架。

完整版教学

一、定位：一致性谱系里最「佛系」的一档

分布式事务方案从强到弱排：2PC（强一致）→ TCC/Saga（业务补偿）→ 本地消息表/事务消息（可靠消息）→ 最大努力通知（最弱）。最大努力通知不追求「一定成功」，它承认「跨系统通知本就可能失败」，转而用「尽力重试 + 提供查询接口让对方来核对」这套组合拳达到最终一致。它适合那些发起方管不了接收方、两个系统甚至属于不同公司的场景。

二、典型场景：支付回调

最经典的例子是第三方支付：用户在你的商城用支付宝付款，支付宝那边扣款成功后，要异步通知你的商城「这笔订单支付成功了」。但支付宝无法保证这个通知一定送达你的服务器（你的服务器可能刚好宕机、网络抖动）。所以支付宝的设计是：

1. 多次重试通知：支付宝按 2s、5s、10s、1min、… 的递增间隔多次回调你的通知接口，直到你返回 success。
2. 提供查询接口：万一所有回调都没成功，你的商城可以主动调用支付宝的「订单查询」接口去问「这笔到底付了没」。

这就是「最大努力通知」——支付宝尽力通知（重试），你这边有查询接口兜底（对账）。

3、为什么要「递增间隔」重试

如果接收方是短暂故障（重启、网络抖动），短间隔重试能快速补上；如果是长时间故障，密集重试只会浪费资源、打爆对方。所以用逐渐拉长的间隔（退避策略）：先密后疏，既能应对短故障的快速恢复，又避免对持续故障的无效轰炸。到达最大重试次数仍失败，就停止通知、记录状态，等接收方来查询或走对账流程。

三、接收方要做的两件事

1. 幂等处理：因为会被重复通知，接收方处理逻辑必须幂等（用业务流水号去重），不能因为收到两次「支付成功」就发两次货。
2. 主动对账：不能完全依赖通知。接收方应有定时任务，对「本地记录为待确认」的单子主动去发起方查询最终状态，把漏掉的通知补回来。这是最大努力通知最终一致的真正保障——通知是「尽力」，对账才是「兜底」。

记忆点：最大努力通知 = 发起方尽力重试通知（先密后疏）+ 接收方幂等 + 接收方主动查询对账兜底。通知会丢，对账不能丢。

四、和本地消息表/事务消息的区别

它们都属于「可靠消息/最终一致」，但侧重不同：

• 本地消息表/事务消息：解决系统内部「本地事务与消息发送的原子性」，消息一定会被投递、下游一定会消费（可靠投递）。
• 最大努力通知：解决跨系统/跨企业的结果通知，不保证一定送达（尽力而为），靠对方的查询接口和对账兜底。它对一致性的保证更弱，但适应了「无法控制对方系统」的现实。

实际上，最大努力通知的发起方内部往往也用本地消息表/事务消息来保证「通知任务不丢」，两者可以叠加使用。

五、常见误区与追问

这道题不能只背概念，要把「最大努力通知」放回真实分布式系统里解释：谁发起、谁协调、状态如何变化、失败后怎么兜底，以及它和性能、可用性、一致性的取舍。

回答层次	要讲清的内容	容易漏掉的边界
核心结论	最大努力通知由发起方多次重试通知接收方，接收方幂等处理，最终不保证 100% 成功但尽最大努力	不要停在名词解释
流程机制	业务完成后发通知 -> 通知失败按策略重试 -> 接收方幂等确认 -> 超过次数停止自动重试 -> 通过查询接口或对账补偿	说明触发方、参与方、状态变化和兜底
工程取舍	支付回调可按 1、5、10、30 分钟重试多次，仍失败则进入人工或对账流程	分布式事务没有免费强一致，性能、可用性和业务侵入一定要取舍

最大努力通知 面试拆解：
1. 业务完成后发通知
2. 通知失败按策略重试
3. 接收方幂等确认
4. 超过次数停止自动重试
5. 通过查询接口或对账补偿

记忆钩子：先说本地事务失效的原因，再拆协调、补偿、消息、幂等、对账和回滚边界；回答时要紧扣「最大努力通知」这道题，不要把相邻概念混成一段泛泛的分布式套话。

• 误区：最大努力通知等于可靠消息。 它不承诺一定送达，通常还要接收方主动查询或对账兜底。
• 误区：通知失败就立即认为业务失败。 支付等场景业务可能已成功，失败的是通知链路。
• 误区：接收方不用幂等。 重复通知是常态，接收方必须按业务流水去重。
• 追问：适合哪些场景？ 支付回调、状态通知、对账提醒等允许最终确认的场景。
• 追问：为什么要提供查询接口？ 通知可能丢失，接收方可主动查询最终状态。
• 追问：重试策略怎么设计？ 有限次数、逐步退避、记录日志、告警和人工补偿。

六、加强记忆

最大努力通知是一致性要求最低的柔性事务方案：发起方用递增间隔重试尽力通知接收方处理结果，但不保证送达；接收方幂等处理 + 提供查询接口 + 主动对账兜底。典型场景是支付回调这种跨系统、跨企业、网络不可控的结果通知（支付宝异步回调）。和本地消息表/事务消息（保证系统内可靠投递）相比，它更弱、更适应「管不了对方系统」的现实，最终一致靠「尽力通知 + 对账兜底」达成。