RabbitMQ入门简介

1.什么是消息队列

消息队列(Message Queue)是一种应用间的通信方式，消息发送后可以立即返回，由消息系统来确保消息的可靠传递。消息发布者只管把消息发布到 MQ 中而不用管谁来取，消息使用者只管从 MQ 中取消息而不管是谁发布的。这样发布者和使用者都不用知道对方的存在。

2.消息队列的主要作用

消息队列主要解决应用解耦、异步消息、流量削峰等问题，最终实现高性能、高可用、可伸缩以及一致性架构。

3.RabbitMQ介绍

RabbitMQ 是一个由 Erlang 语言开发的 AMQP 的开源实现，主要用于在分布式系统中存储转发消息，在易用性、扩展性以及高可用性等方面表现不俗，具有可靠性、灵活路由、消息集群、高可用、多协议、多语言、管理界面、跟踪机制以及插件机制等特点。

4.RabbitMQ架构设计

Broker：表示消息队列服务器实体。

Queue：队列，是RabbitMQ的内部对象，用于存储消息。RabbitMQ中消息只能存储在队列中。生产者投递消息到队列，消费者从队列中获取消息并消费。多个消费者可以订阅同一个队列，这时队列中的消息会被平均分摊(轮询)给多个消费者进行消费，而不是每个消费者都收到所有的消息进行消费。(注意：RabbitMQ不支持队列层面的广播消费，如果需要广播消费，可以采用一个交换器通过路由Key绑定多个队列，由多个消费者来订阅这些队列的方式。

Exchange：交换器。生产者将消息发送到Exchange，由交换器将消息路由到一个或多个队列中。如果路由不到，或返回给生产者，或直接丢弃，或做其它处理。

RoutingKey：路由Key。生产者将消息发送给交换器的时候，一般会指定一个RoutingKey，用来指定这个消息的路由规则。这个路由Key需要与交换器类型和绑定键(BindingKey)联合使用才能最终生效。在交换器类型和绑定键固定的情况下，生产者可以在发送消息给交换器时通过指定RoutingKey来决定消息流向哪里。

Binding：通过绑定将交换器和队列关联起来，在绑定的时候一般会指定一个绑定键，这样RabbitMQ就可以指定如何正确的路由到队列了。

Channel：信道是建立在Connection 之上的虚拟连接。当应用程序与Rabbit Broker建立TCP连接的时候，客户端紧接着可以创建一个AMQP 信道(Channel) ，每个信道都会被指派一个唯一的ID。RabbitMQ 处理的每条AMQP 指令都是通过信道完成的。信道就像电缆里的光纤束。一条电缆内含有许多光纤束，允许所有的连接通过多条光线束进行传输和接收。

Message：消息，消息是不具名的，它由消息头和消息体组成。消息体是不透明的，而消息头则由一系列的可选属性组成，这些属性包括routing-key（路由键）、priority（相对于其他消息的优先权）、delivery-mode（指出该消息可能需要持久性存储）等。

Producer：消息的生产者，即向消息队列发布消息的主体。

Consumer：消息的消费者，即订阅消息队列中的消息，从而获取消息进行消费。

简而言之，

在生产者方面，生产者(Producer)将产生的消息(Message)送入Rabbit Broker中的交换器(Exchange)，同时指定路由键(RoutingKey)，通过交换器(Exchange)以及一个绑定键(BindingKey)与队列(Queue)进行绑定，最终将消息存储消息队列当中；

而在消费者方面，消费者(Consumer)通过与Rabbit Broker建立TCP连接，而后创建信道(Channel)，同时指派一个ID，最终完成与消息队列的连接，获取消息。

5.RabbitMQ可靠性原理

发送方确认机制：信道需要设置为 Confirm 模式，则所有在信道上发布的消息都会分配一个唯一 ID。一旦消息被投递到Queue(可持久化的消息需要写入磁盘)，信道会发送一个确认给生产者(包含消息唯一 ID)。如果 RabbitMQ 发生内部错误从而导致消息丢失，会发送一条 Nack(未确认)消息给生产者。所有被发送的消息都将被 Confirm(即 Ack) 或者被Nack一次。但是没有对消息被 confirm 的快慢做任何保证，并且同一条消息不会既被Confirm又被Nack发送方确认模式是异步的，生产者应用程序在等待确认的同时，可以继续发送消息。当确认消息到达生产者，生产者的回调方法会被触发。

接收方确认机制：消费者在声明队列时，可以指定noAck参数，当noAck=false时，RabbitMQ会等待消费者显式发回ack信号后才从内存(或者磁盘，持久化消息)中移去消息。否则，消息被消费后会被立即删除。消费者接收每一条消息后都必须进行确认(消息接收和消息确认是两个不同操作)。只有消费者确认了消息，RabbitMQ 才能安全地把消息从队列中删除。

RabbitMQ不会为未Ack的消息设置超时时间，它判断此消息是否需要重新投递给消费者的唯一依据是消费该消息的消费者连接是否已经断开。这么设计的原因是RabbitMQ允许消费者消费一条消息的时间可以很长。保证数据的最终一致性；

消息重复性：如果消费者返回Ack之前断开了链接，RabbitMQ 会重新分发给下一个订阅的消费者。(可能存在消息重复消费的隐患，需要去重)

ConfirmCallback接口：只确认是否正确到达 Exchange 中，成功到达则回调

ReturnCallback接口 ：消息失败返回时回调

6.消息队列对比

Kafka：

• 优点： 吞吐量非常大，性能非常好，集群高可用。

• 缺点：会丢数据，功能比较单一。

• 使用场景：日志分析、大数据采集

RabbitMQ：

• 优点： 消息可靠性高，功能全面。

• 缺点：吞吐量比较低，消息积累会严重影响性能。erlang语言不好定制。

• 使用场景：小规模场景。

RocketMQ：

• 优点：高吞吐、高性能、高可用，功能非常全面。

• 缺点：开源版功能不如云上商业版。官方文档和周边生态还不够成熟。客户端只支持java。

• 使用场景：几乎是全场景。