分布式解决方案 --基于最大努力通知型方案

基于最大努力通知型

• 业务活动的主动方，在完成业务处理之后，向业务活动的被动方发送消息，允许消息丢失。
• 业务活动的被动方根据定时策略，向业务活动主动方查询，恢复丢失的业务消息。
• 被动方的处理结果不影响主动方的处理结果

方案特点
• 业务活动的主动方在完成业务处理后，向业务活动被动方发送通知消息（允许消息丢失）
• 主动方可以设置时间阶梯型通知规则，在通知失败后按规则重复通知，直到通知N次后不再通知
• 主动方提供校对查询接口给被动方按需校对查询，用于恢复丢失的业务消息
• 行业应用案例,银行通知、商户通知等（各大交易业务平台间的商户通知：多次通知、查询校对、对账文件）

懒得画图了，手动画了一个。

执行步骤：
1 主动方（比如电商系统的交易微服务模块）调用消息服务将消息发送到mq(消息存在丢失情况)[a,b步骤]

2 消息服务端监听MQ消息，将获取的消息解析，将需要通知的内容(notify_record)保存到DB，并将消息发送到延时队列DelayQueue服务任务中[c,d步骤]，此时是第一次通知

3 通知服务运行时，将延迟队列中满足当前运行时刻的任务执行,将通知的任务发送给被动方（比如电商系统中的商户服务模块）。[e,f步骤]

针对3描述的执行任务，有如下处理逻辑：

a .将通知发送商户时，调动商户接口，（此步骤可插入通知日志表（notify_record_log）用于记录多次通知的日志情况），如果商户返回成功success标识后，
更新通知记录表（notify_record）状态成功，以后不再通知。

b. 如果通知不成功（返回标识不是success）,判断 notify_record表中通知次数是否达到最大通知次数，如果没有，添加进延迟队列（DelayQueue），否则更新notify_record表状态
通知失败，以后不再通知。

异常情况的处理过程：

1. mq服务宕机，消息服务往mq生成消息后发送会失败。导致整个通知服务不成功，通知不会成功通知到被动方（商户）。

   这部分可参照实际情况做修改，在某些案例中，该情况并不影响整个服务，比如，用户通过支付宝下单后，支付宝回调我们主动方（交易）服务，主动方
   服务需要发送通知，告知商户，通过我们如图的步骤发送mq，如果说mq发送失败了，我们在业务逻辑中，就不要给支付宝返回success，
   这样支付宝会一直重复回调主动方的接口，直到我们这边服务正常处理，给支付宝返回success。

2. mq消费端异常（监听端）,我们这mq这边可设置消息的手动确认，如果业务处理正常，手动确认，如果处理异常，就不确认了，这样mq还会发送该消息。

3. 图中其他步骤失败的话，由于我们在2的情况中，如果业务处理正常，会将通知消息存储DB,并塞入延迟队列，此后的步骤失败了，会由通知服务，
   将延迟队列中或者数据库中未失败且未达最大通知次数的消息塞入延迟队列，到预定时间，重新执行。 如果商户系统挂了的话，达到最大通知次数
   后，就不再通知了，最好需要提供被动方查询的接口供被动方使用，等待被动方服务恢复后，可查询主动方接口，调整自己的业务。