分布式事务解决方案——最大努力通知以及解决方案

什么是最大努力通知

分布式系统中，服务之间的互相调用有时候在某些业务场景下，被调用者需要将业务处理结果再通知到调用者，调用者才能继续完成后续的业务操作，在这种场景下要保证业务的连续性、完整性、最终一致性等，就需要消息通知的可靠性至关重要。结合以上的分析，最大努力通知就是服务间的消息通知，要尽可能的设计和使用某些策略手段，达到最接近100%的通知成功率。

场景简单举栗

下单扣减库存场景：

1. 订单服务收到下单的请求开始执行下单业务逻辑
2. 订单服务处理了一定的前置业务逻辑后，需要通知库存服务扣减库存
3. 库存服务接收到消息通知之后扣减库存，需要把结果告诉订单服务
4. 订单服务接收到库存服务的通知结果，继续后续的业务逻辑，如订单状态的改变

在该场景中，一共存在两次通知：订单 to 库存、库存 to 订单，这两次都可能出现通知失败的情况。

• 在step 2中通知发送的时候，会向本地的数据库插入一条业务通知数据，该条数据有通知是否发送成功的状态字段，只有当step 4执行无误后，订单服务成功的接收到通知才会改变该业务通知的状态
• 可以存在一个轮询任务，去轮询通知数据表中没有发送成功的数据，继续向库存服务发送该通知，记录发送的该条通知的次数
• 库存服务处理完扣减业务之后发送通知到订单服务，也要像订单服务的通知一样存在一定的消息重复通知机制
• 订单服务可以提供一个接口供库存服务查询通知的状态，让库存服务也“有据可循”的重复发送通知到订单服务（最大努力通知的体现）

总结为两点

1. 通知一定要存在按照某些既定的策略重复发送通知的机制，
2. 通知方要存在通知发送成功的确认机制

与可靠消息一致性的不同

可靠消息一致性可参考另一篇博文：分布式事务解决方案——可靠消息最终一致性（本地消息表、MQ自身提供的可靠性保证）

解决方案思想不同

可靠消息一致性，发起通知方需要保证将消息发出去，消息的可靠性关键由通知方保证、

最大努力通知，发起通知方尽最大的努力的发消息给消费方，但是消息可能接收不到，此时需要消费方主动调用通知发送方的接口查询业务处理结果，通知的可靠性关键在消费方

两者的业务应用场景不同

可靠消息一致性关注的是业务处理中的业务一致性，以异步的方式完成业务处理。

最大努力通知关注的是业务处理后的通知事务，即将业务处理结果通知可靠的发送出去

技术解决方向不同

可靠消息一致性要解决消息从发送到接收的一致性，即消息发出并且一定能接收到

最大努力通知无法保证消息从发送到接收的一致性，只提供消息接受的可靠性机制。可靠机制：最大努力的将消息发送给接收方，当消息无法被接收方消费的时候，由接收方主动查询消息

解决方案

方案1：

本图所示是利用MQ的ack机制向消费者发送生产者的消息，流程如下：

1. 通知方发送通知到MQ
2. 接收方监听MQ的消息队列
3. 接收方接收到消息后处理业务，全部完成后回应MQ ack
4. 接收方若没有回应ack，则MQ会重复发送该条业务消息
5. 接收方通过通知方提供的接口校对消息发送的一致性

方案2：

与方案1思路类似不同点是采用了一个单独的通知系统来对MQ进行消息的监听：

1. 方案1中接收方直接监听MQ，只适合内部系统之间的消息通知
2. 方案2中由通知系统来监听MQ消息，收到MQ消息之后由通过互联网接口协议调用通知方，适用于外部系统之间的通知，典型的方案2有支付宝、微信对接回调