分布式事务之最大努力通知型

Posted 2021-03-31 家园叮咚

柔性事务解决方案：最大努力通知（定期校对）

实现

业务活动的主动方，在完成业务处理之后，向业务活动的被动方发送消息，被动方需主动响应正确消息,否则根据定时策略,最大努力通知。

业务活动的被动方也可以向业务活动主动方查询，恢复丢失的业务消息。

约束

    被动方的处理结果不影响主动方的处理结果。

成本

   业务查询与校对系统的建设成本

适用范围

   对业务最终一致性的时间敏感度低

   跨企业的业务活动

柔性事务解决方案：最大努力通知（定期校对）

方案特点

  业务活动的主动方在完成业务处理后，向业务活动被动方发送通知消息（允许消息丢失）主动方可以设置时间阶梯型通知规则，在通知失败后按规则重复通知，直到通知N次后不主动方提供校对查询接口给被动方按需校对查询，用于恢复丢失的业务消息

应用案例

银行通知、商户通知等（各大交易业务平台间的商户通知：多次通知、查询校对、对账文件）

Rabbitmq延迟队列实现原理：

由于rabbitmq本身并没有提供延迟队列的功能，所以需要借助

1、rabbitmq 可以针对 Queue和Message 设置x-message-ttl 来控制消息的生存时间，如果超时，消息变为dead letter（死信）

2、rabbitmq 的queue 可以配置 x-dead-letter-exchange 和 x-dead-letter-routing(可选)

  两个参数，来控制队列出现  dead letter 的时候，重新发送消息的目的地

比如：假设设置一条消息存活时间为10秒钟，那么10秒钟之后，如果没有消费者消费，这条消息就会变为dead letter（死信），就会把该消息转发到指定交换机跟队列当中，然后被消费

在队列上指定一个Exchange，则在该队列上发生如下情况，

1.消息被拒绝（basic.reject or basic.nack)，且requeue=false

2.消息过期而被删除（TTL）

3.消息数量超过队列最大限制而被删除

4.消息总大小超过队列最大限制而被删除

就会把该消息转发到指定的一个exchange

同时也可以指定一个可选的x-dead-letter-routing-key，表示默认的routing-key，如果没有指定，则使用消息的routeing-key(也跟指定的exchange有关，如果是Fanout类型的exchange，则会转发到所有绑定到该exchange的所有队列）