场景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进行对比，这样可以确保生产端的消息表中的没有进行回调确认（或者回调确认时网络问题）的消息进行补救式的重发，当然不可避免的就会在消息端可能会造成消息的重复消息。针对消费端重复消息，在消费端进行幂等处理。（丢消息和重复消息是不可避免的二个极端，比起丢消息，重复消息还有补救措施，而消息丢失就真的丢失了

Rabbitmq如何保证消息不丢失

生产者提交给消息服务器时，使用确认机制
消息服务器对应的队列、交换机等都持久化，保证数据的不丢失
消费者采用消息确认机制，保证数据的不丢失

RabbitMQ的7种典型使用场景相关推荐

SSD固态盘应用于Ceph集群的四种典型使用场景
在虚拟化及云计算技术大规模应用于企业数据中心的科技潮流中,存储性能无疑是企业核心应用是否虚拟化.云化的关键指标之一.传统的做法是升级存储设备,但这没解决根本问题,性能和容量不能兼顾,并且解决不好设备利 ...
细数阿里云服务器的十二种典型应用场景
原文链接:http://click.aliyun.com/m/13910/ 免费开通大数据服务:https://www.aliyun.com/product/odps 文章转载:小白杨1990 如今, ...
Oracle Text 全文索引几种典型应用场景
一.普通查询这是OracleText比较普遍且常用的应用场景.创建OracleText中Context类型的索引,生成大量的关键词,用于加快类似于普通的like '%xx%'操作速度,或者查询一些比 ...
常见的八种典型知识变现场景
很多人问我,希望自己的知识变现,但是不知道自己的知识,可以通过什么样的具体场景,才能变成钱,知识通过什么渠道和方式才能变现. 今天,我简单梳理了一下,其实,知识变现的场景很多,比如一场讲座.一次直播. ...
day72 JavaWeb框架阶段——RabbitMQ消息队列【了解常见的MQ产品，了解RabbitMQ的5种消息模型，会使用Spring AMQP】
文章目录 0.学习目标 1.RabbitMQ 1.1.搜索与商品服务的问题 1.2.消息队列(MQ) 1.2.1.什么是消息队列 1.2.2.AMQP和JMS 1.2.3.常见MQ产品 1.2.4.R ...
【分布式】Rabbitmq死信队列模型、实战场景---订单延迟30min支付处理
分布式内容管理死信队列死信队列demo 死信队列消息模型平台订单支付超时 --- 演示业务分析代码实现 RabbitMQ 死信队列/ 延迟队列 - 延迟业务逻辑最近可能分布式进入Redi ...
ZooKeeper典型应用场景一览
原文地址:http://jm-blog.aliapp.com/?p=1232 ZooKeeper典型应用场景一览数据发布与订阅(配置中心) 发布与订阅模型,即所谓的配置中心,顾名思义就是发布者将数据 ...
【ZooKeeper Notes 28】ZooKeeper典型应用场景一览
ZooKeeper是一个高可用的分布式数据管理与系统协调框架.基于对Paxos算法的实现,使该框架保证了分布式环境中数据的强一致性,也正是基于这样的特性,使得ZooKeeper解决很多分布式问题.网上 ...
Zookeeper分布式一致性原理（八）：Zookeeper典型应用场景
1. 简介 Zookeeper是一个高可用的分布式数据管理和协调框架,并且能够很好的保证分布式环境中数据的一致性.在越来越多的分布式系统(Hadoop.HBase.Kafka)中,Zookeeper都 ...
Zookeeper的典型应用场景（1）
此文知识来自于:<从Paxos到Zookeeper分布式一致性原理与实践>第六章数据发布/订阅(配置中心) 负载均衡(DNS解析) 命名服务(顺序节点特性) 分布式协调/通知(Watch ...

RabbitMQ的7种典型使用场景