什么是RabbitMQ？它的特性是什么
RabbitMQ 最初起源于金融系统，用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。具体特点包括：
1、可靠性（Reliability）
2、灵活的路由（Flexible Routing）
在消息进入队列之前，通过 Exchange 来路由消息的。对于典型的路由功能，RabbitMQ 已经提供了一些内置的 Exchange 来实现。针对更复杂的路由功能，可以将多个 Exchange 绑定在一起，也通过插件机制实现自己的 Exchange 。
3、消息集群（Clustering）
多个 RabbitMQ 服务器可以组成一个集群，形成一个逻辑 Broker 。
4、高可用（Highly Available Queues）
队列可以在集群中的机器上进行镜像，使得在部分节点出问题的情况下队列仍然可用。
6、多语言客户端（Many Clients）
RabbitMQ 几乎支持所有常用语言，比如 Java、.NET、Ruby 等等。
队列、路由概念
Quque（队列）是RabbitMQ的内部对象，用于存储信息，
生产者将消息发送到Exchange（交换器，下图中X），Exchange将消息路由到一个或者多个Quque中或者丢弃
routing key（路由key）
生产者在将消息发送给Exchange的时候，一般会指定一个routing key，来指定这个路由规则，而这个routing key需要与 Exchange Type 与binding key 联合使用才能最终生效。
RabbitMQ 中的 Broker 是指什么？Cluster 又是指什么？
Broker ，是指一个或多个 erlang node 的逻辑分组，且 node 上运行着 RabbitMQ 应用程序。
Cluster ，是在 Broker 的基础之上，增加了 node 之间共享元数据的约束。
什么是元数据？元数据分为哪些类型？包括哪些内容？
在非 Cluster 模式下，元数据主要分为：
Queue 元数据（queue 名字和属性等）
Exchange 元数据（exchange 名字、类型和属性等）
Binding 元数据（存放路由关系的查找表）
Vhost 元数据（vhost 范围内针对前三者的名字空间约束和安全属性设置）。
RabbitMQ 概念里的 channel、exchange 和 queue 是什么？
queue 具有自己的 erlang 进程；
exchange 内部实现为保存 binding 关系的查找表；
channel 是实际进行路由工作的实体，即负责按照 routing_key 将 message 投递给 queue 。
如何确保消息正确地发送至 RabbitMQ？
RabbitMQ 使用发送方确认模式，确保消息正确地发送到 RabbitMQ。
发送方确认模式：将信道设置成 confirm 模式（发送方确认模式），则所有在信道上发布的消息都会被指派一个唯一的 ID 。一旦消息被投递到目的队列后，或者消息被写入磁盘后（可持久化的消息），信道会发送一个确认给生产者（包含消息唯一ID）。如果 RabbitMQ 发生内部错误从而导致消息丢失，会发送一条 nack（not acknowledged，未确认）消息。
发送方确认模式是异步的，生产者应用程序在等待确认的同时，可以继续发送消息。当确认消息到达生产者应用程序，生产者应用程序的回调方法就会被触发来处理确认消息。
消息发送的整个流程
消息发布到交换器时，消息将拥有一个路由键（routing key），在消息创建时设定。
通过队列路由键，可以把队列绑定到交换器上。
消息到达交换器后，RabbitMQ 会将消息的路由键与队列的路由键进行匹配（针对不同的交换器有不同的路由规则）。如果能够匹配到队列，则消息会投递到相应队列中；如果不能匹配到任何队列，消息将进入 “黑洞”。
常用的交换器有哪些
常用的交换器主要分为一下三种：
direct：如果路由键完全匹配，消息就被投递到相应的队列。
fanout：如果交换器收到消息，将会广播到所有绑定的队列上。
topic：可以使来自不同源头的消息能够到达同一个队列。 使用 topic 交换器时，可以使用通配符，比如：“*” 匹配特定位置的任意文本， “.” 把路由键分为了几部分，“#” 匹配所有规则等。特别注意：发往 topic 交换器的消息不能随意的设置选择键（routing_key），必须是由 "." 隔开的一系列的标识符组成。
RabbitMQ中实现RPC的机制是：
客户端发送请求（消息）时，在消息的属性（MessageProperties，在AMQP协议中定义了14中properties，这些属性会随着消息一起发送）中设置两个值replyTo（一个Queue名称，用于告诉服务器处理完成后将通知我的消息发送到这个Queue中）和correlationId（此次请求的标识号，服务器处理完成后需要将此属性返还，客户端将根据这个id了解哪条请求被成功执行了或执行失败）
服务器端收到消息并处理
服务器端处理完消息后，将生成一条应答消息到replyTo指定的Queue，同时带上correlationId属性
客户端之前已订阅replyTo指定的Queue，从中收到服务器的应答消息后，根据其中的correlationId属性分析哪条请求被执行了，根据执行结果进行后续业务处理
details/50349603
版权声明：本文为博主原创文章，转载请附上博文链接！
相关文章
