分布式事务之最大努力通知型
柔性事务解决方案：最大努力通知（定期校对）
实现
业务活动的主动方，在完成业务处理之后，向业务活动的被动方发送消息，被动方需主动响应正确消息,否则根据定时策略,最大努力通知。
业务活动的被动方也可以向业务活动主动方查询，恢复丢失的业务消息。
约束
被动方的处理结果不影响主动方的处理结果。
成本
业务查询与校对系统的建设成本
适用范围
对业务最终一致性的时间敏感度低
跨企业的业务活动
柔性事务解决方案：最大努力通知（定期校对）
方案特点
业务活动的主动方在完成业务处理后，向业务活动被动方发送通知消息（允许消息丢失）主动方可以设置时间阶梯型通知规则，在通知失败后按规则重复通知，直到通知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的所有队列）