本文讨论了在支付模块中使用topic模式而非direct模式的原因，强调了topic模式在处理回调通知、简化配置和提高消息可靠性方面的优点，特别是在处理网络故障、服务中断等情况下的订单状态更新。
插一个额外的话题
比如我们有一个支付模块，然后下单成功后修改支付模块的状态，同时告诉客户支付成功
这里使用的是topic模式 为什么不用direct模式
好处一：如果使用topic 当我的支付的回调中如果给我支付成功，我的路由key可以写成pay.success 这样2个模块都可以通知到，当在回调中失败，pay.error这样通知模块可以收到消息就可以通知到用户，或输入pay.wait 也可以通知客户，正在支付中，请等待
好处二：这样我只需要创建一个创建机，2个队列，然后再创建2个路由进行绑定 ，
如果是direct交换机，我需要创建一个交换机，2个队列，但是我要创建多pay.success,pay.error,pay.write等多个key然后进行绑定 比较费劲
rabbitMq消息的可靠性
以下场景可以证明一个rabbimq的可靠性的重要性
一：我支付模块调用rabbimq，但是可能会出现网络故障，相当于rabbimq没有收到消息，订单状态未改变
二：rabbimt收到消息，但是还没有来得及处理，rabbimq服务器挂了，这时候也没有收到消息
订单状态未改变
三：rabbimtq发送到交易服务，但是交易服务抛出了异常，这时候订单状态也没有改变
消息的可靠性就是保证发送一条消息，并保证这条消息至少被消费一次。
所以有3种可能性会出现丢失
发送者丢失消息 rabbitmq丢失消息 消费者丢失消息
这是后面的内容，最后的延迟消息是兜底模式
339
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
