RabbitMQ基础概念

名词概念

RabbitMQ是使用Erlang语言编写，基于AMQP协议实现的消息代理与队列服务器。消息队列的作用：解耦、提速、广播、削峰，主要目的是为了减少响应时间。应用在耗时较长，但不需要立即返回结果的情景。

服务器结构组成：

名称	职能	说明
Broker	服务器实体
Virtual Host	虚拟主机	标识交换机、消息队列与相关对象。每个虚拟主机拥有自己的服务域，存在自己的队列、交换器、绑定和权限机制，必须在连接的时候进行制定。默认的虚拟主机为"/"
Exchange	交换器	接收生产者的消息并交给服务器中的队列
Queue	消息队列	保存消息直到消费者取走。消息的容器，一个消息可投入一个或多个消息队列
Banding	绑定	消息队列与交换器的关联。基于路由键将交换器与队列连接起来的路由规则
Channel	信道	多路复用连接中一条独立的双向数据流通道。AMQP命令通过信道，复用一条TCP连接进行通信
Connection	网络连接	比如TCP连接
Publisher	生产者	向交换器发布消息的客户端程序
Consumer	消费者	从队列中取得消息的客户端程序
Message	消息	由消息头与消息体组成。消息体不透明，消息头包含一些可选属性，如routing-key(路由键)、priority(优先级)、delivery-mode(持久性存储)

Exchange类型

根据不同的分发策略，分为direct、fanout、topic、headers四种类型

交换器类型	说明
direct	直联类型。通过路由完全匹配，将消息转发到路由键与队列名完全一致的队列中
fanout	发散类型。不使用匹配路由键的方式，将消息直接发送给所有绑定该交换器的队列
topic	订阅类型。通过模式匹配分配消息的路由键属性，队列需要首先绑定到一个模式上，通过“路由键”与“模式键”的组合，来匹配交换器的消息。同时识别两个通配符“#”、“*”

topic交换器类型

死信机制

消息并不是一直都是处于可消费的状态，当出现以下情况，则认为该消息为“死信”：

• 消息被否定确认，使用 channel.basicNack 或 channel.basicReject ，并且此时requeue 属性被设置为false
• 消息在信道中的存活时间超过设定的TTL时间（Time to Live生存时间）
• 消息队列中的消息数量已经超过队列最大长度

TTL可在创建Exchange时配置，也可以在消息发送时，在消息体中进行指定

当消息被判定为“死信”时，会将该消息转发到死信交换器，死信交换器可通过不同的分发策略，将消息存入绑定的“死信队列”。一般会为每个重要的业务队列，独立的配置一个死信队列。通过监听死信队列，可对死信消息进行消费，

死信队列也可配置相应的死信交换器与死信队列
利用死信机制，可实现延时队列。保证在高精度、大数据量的要求下，避免通过定时任务的方式进行延时任务处理

死信队列中过期消息还是遵循先进先出，如果要打破这个限制，需要安装插件rabbitmq_delayed_message_exchange。相关链接

生产者Confirm机制

生产者产生消息后，会将消息投递给Broker。如果Broker收到消息，会返回确认的应答信息，生产者通过接受应答，来确认该消息被正确投递。

开启Confirm机制的方式：

• 第一步，在channel上开启确认模式：channel.confirmSelect()
• 第二步，在channel上添加监听：addConfirmListener，监听成功和失败的返回结果，根据具体的结果对消息进行重新发送、或记录日志等后续处理

不仅在生产者有消息确认机制，消费者也有确认机制

可靠性保证

消息的可靠性包括：

1. 保证消息的成功发出
2. 保证消息的成功接收
3. 发送端收到Broker的确认应答
4. 完善消息补偿机制

解决方案：

• 一. 消息落库。但不适合高并发下的场景
• 二. 二次确认，消息延时投递，回调检查。减少了对库的操作，同时解耦，保证了性能，但不能完全保证可靠性

限流操作

当有大量的消息被产生时，消费者会被瞬间挤入超过本身机器处理能力的消息数据，可能会造成消息堵塞，甚至可能会造成宕机等严重后果。生产者不太能做限流处理，因为生产者代表着用户行为，不能够限制用户的操作来保证服务的可用，所以就需要在消费者进行限流操作。

RabbitMQ提供一种qos机制，在关闭自动确认的模式下，如果一定数量的消息未被确认，则不会进行新消息的消费，这样保证了消费端的可用性，对海量的消息进行限流处理。

参考文章链接：

透彻rabbitmq
消息队列的使用场景是怎样的？
一文带你搞定RabbitMQ死信队列
一文带你搞定RabbitMQ延迟队列