RabbitMQ的7种典型使用场景_rabbitmq的使用场景-CSDN博客

本文链接：https://blog.csdn.net/m0_67391120/article/details/126585525

场景1：单发送单接收

使用场景：简单的发送与接收，没有特别的处理。

一个P向queue发送一个message，一个C从该queue接收message并打印。producer，连接至RabbitMQ Server，声明队列，发送message，关闭连接，退出。

场景2：单发送多接收

使用场景：一个发送端，多个接收端，如分布式的任务派发。为了保证消息发送的可靠性，不丢失消息，使消息持久化了。同时为了防止接收端在处理消息时down掉，只有在消息处理完成后才发送ack消息。

场景3：Publish/Subscribe(发布、订阅模式)

发送端发送广播消息，多个接收端接收。

使用"fanout"方式发送，即广播消息，不需要使用queue，发送端不需要关心谁接收

场景4：Routing (按路线发送接收)

使用场景：发送端按routing key发送消息，不同的接收端按不同的routing key接收消息。

在这个场景中，我们可以看到直连交换机 X 和两个队列进行了绑定。第一个队列使用 orange 作为绑定键，第二个队列有两个绑定，一个使用 black 作为绑定键，另外一个使用 green。这样以来，当路由键为 orange 的消息发布到交换机，就会被路由到队列 Q1。路由键为 black 或者 green 的消息就会路由到 Q2。其他的所有消息都将会被丢弃。

多个绑定（Multiple bindings）

多个队列使用相同的绑定键是合法的。这个例子中，我们可以添加一个 X 和 Q1 之间的绑定，使用 black 绑定键。这样一来，直连交换机就和扇型交换机的行为一样，会将消息广播到所有匹配的队列。带有 black 路由键的消息会同时发送到 Q1 和 Q2。

场景5：Topics (按topic发送接收)

使用场景：发送端不只按固定的routing key发送消息，而是按字符串“匹配”发送，接收端同样如此。

主题交换机是很强大的，它可以表现出跟其他交换机类似的行为。

场景6：PRC

尽管 RPC 在计算领域是一个常用模式，但它也经常被诟病。当一个问题被抛出的时候，程序员往往意识不到这到底是由本地调用还是由较慢的 RPC 调用引起的

我们的 RPC 如此工作:

当客户端启动的时候，它创建一个匿名独享的回调队列。
在 RPC 请求中，客户端发送带有两个属性的消息：一个是设置回调队列的 reply_to 属性，另一个是设置唯一值的 correlation_id 属性。
将请求发送到一个 rpc_queue 队列中。
RPC 工作者（又名：服务器）等待请求发送到这个队列中来。当请求出现的时候，它执行他的工作并且将带有执行结果的消息发送给 reply_to 字段指定的队列。
客户端等待回调队列里的数据。当有消息出现的时候，它会检查 correlation_id 属性。如果此属性的值与请求匹配，将它返回给应用。整合到一起

场景7：发布者确认

Publisher Confirms是RabbitMQ扩展，可以实现可靠的发布。在通道上启用发布者确认后，代理将异步确认客户端发布的消息，这意味着它们已在服务器端处理。

生产者与broker之间的消息确认称为public confirms，public confirms机制用于解决生产者与Rabbitmq服务器之间消息可靠传输，它在消息服务器持久化消息后通知消息生产者发送成功。

生产者与broker之间的消息可靠性保证的基本思路就是当消息发送到broker的时候，会执行监听的回调函数，其中deliveryTag是消息id（deliveryTag投递的标识，当Channel设置成confirm模式时，发布的每一条消息都会获得一个唯一的deliveryTag，任何channel上发布的第一条消息的deliveryTag为1，此后的每一条消息都会加1，deliveryTag在channel范围内是唯一的。）在同一个channel中这个数值是递增的，而multiple表示是否批量确认消息。
在生产端要维护一个消息发送的表，消息发送的时候记录消息id，在消息成功落地broker磁盘并且进行回调确认（ack）的时候，根据本地消息表和回调确认的消息id进行对比，这样可以确保生产端的消息表中的没有进行回调确认（或者回调确认时网络问题）的消息进行补救式的重发，当然不可避免的就会在消息端可能会造成消息的重复消息。针对消费端重复消息，在消费端进行幂等处理。（丢消息和重复消息是不可避免的二个极端，比起丢消息，重复消息还有补救措施，而消息丢失就真的丢失了