RabbitMQ

一、RabbitMQ原理介绍

a. Message : 消息。消息是不具名称的，它由消息头消息体组成。消息体是不透明的，而消息头则由一系列可选属性组成，这些属性包括：routing-key(路由键)、priority(相对于其他消息的优先权)、delivery-mode(指出消息可能持久性存储)等。
b. Publisher : 消息的生产者。也是一个向交换器发布消息的客户端应用程序。
c. Consumer : 消息的消费者。表示一个从消息队列中取得消息的客户端应用程序。
d. Exchange : 交换器。用来接收生产者发送的消息并将这些消息路由给服务器中的队列。
e. 三种常用的交换器类型 : direct(发布与订阅 完全匹配)、fanout(广播)、topic(主题，规则匹配)
f. Binding : 绑定。用于消息队列和交换器之间的关联。一个绑定就是基于路由键将交换器和消息队列连接起来的路由规则，所以可以将交换器理解成一个由绑定构成的路由表。
g. Queue ： 消息队列。用来保存消息直到发送给消费者。它是消息的容器，也是消息的终点。一个消息可投入一个或多个队列。消息一直在队列里面，等待消费者链接到这个队列将其取走。
h. Routing-key: 路由键。RabbitMQ决定消息该投递到哪个队列的规则。队列通过路由键绑定到交换器。消息发送到MQ服务器时，消息将拥有一个路由键，即便是空的，RabbitMQ也会将其和绑定使用的路由键进行匹配。如果相匹配，消息将会投递到该队列。如果不匹配，消息将会进入黑洞。
i. Connection : 链接。指rabbit服务器和服务建立的TCP链接。
j. Channel : 信道。Channel中文叫做信道，是TCP里面的虚拟链接。例如：电缆相当于TCP，信道是一个独立光纤束，一条TCP连接上创建多条信道是没有问题的。TCP一旦打开，就会创建AMQP信道。无论是发布消息、接收消息、订阅队列，这些动作都是通过信道完成的。
k. Virtual Host : 虚拟主机。表示一批交换器，消息队列和相关对象。虚拟主机是共享相同的身份认证和加密环境的独立服务器域。每个vhost本质上就是一个mini版的RabbitMQ服务器，拥有自己的队列、交换器、绑定和权限机制。vhost是AMQP概念的基础，必须在链接时指定，RabbitMQ默认的vhost是/
l. Borker: 表示消息队列服务器实体。就是RabbitMQ整体应用。
m. 交换器和队列的关系 : 交换器是通过路由键和队列绑定在一起的，如果消息拥有的路由键跟队列和交换器的路由键匹配，那么消息就会被路由到该绑定的队列中。也就是说，消息到队列的过程中，消息首先会经过交换器，接下来交换器在通过路由键匹配分发消息到具体的队列中。路由键可以理解为匹配的规则。
n. RabbitMQ为什么需要信道？为什么不是TCP直接通信？
TCP的创建和销毁开销特别大。创建需要3次握手，销毁需要4次分手。
如果不用信道，那应用程序就会以TCP链接Rabbit，高峰时每秒成千上万条链接会造成资源巨大的浪费，而且操作系统每秒处理TCP链接数也是有限制的，必定造成性能瓶颈。
信道的原理是一条线程一条通道，多条线程多条通道同用一条TCP链接。一条TCP链接可以容纳无限的信道，即使每秒成千上万的请求也不会成为性能的瓶颈。

二、RabbitMQ应用

Direct交换器 : 是一种点对点，实现发布/订阅标准的交换器。Producer发送消息到RabbitMQ中，MQ中的Direct交换器接受到消息后，会根据Routing Key来决定这个消息要发送到哪一个队列中。Consumer则负责注册一个队列监听器，来监听队列的状态，当队列状态发生变化时，消费消息。注册队列监听需要提供交换器信息，队列信息和路由键信息。
这种交换器通常用于点对点消息传输的业务模型中。如电子邮箱。

producer全局配置文件

spring.application.name=direct-producer

# 必要配置
# 配置rabbitmq链接相关信息。key都是固定的。是springboot要求的。
# rabbitmq安装位置
spring.rabbitmq.host=192.168.1.122
# rabbitmq的端口
spring.rabbitmq.port=5672
# rabbitmq的用户名
spring.rabbitmq.username=test
# rabbitmq的用户密码
spring.rabbitmq.password=123456

# 可选配置
# 配置producer中操作的Queue和Exchange相关信息的。key是自定义的。为了避免硬编码。
# exchange的命名。交换器名称可以随意定义。
mq.config.exchange=log.direct
# 路由键， 是定义某一个路由键。 info级别日志使用的queue的路由键。
mq.config.queue.info.routing.key=log.info.routing.key
# 路由键，error级别日志使用的queue的路由键。
mq.config.queue.error.routing.key=log.error.routing.key
Consumer全局配置
spring.application.name=direct-consumer

server.port=8081

spring.rabbitmq.host=192.168.1.122
spring.rabbitmq.port=5672
spring.rabbitmq.username=test
spring.rabbitmq.password=123456

# 自定义配置。 配置交换器exchange、路由键routing-key、队列名称 queue name
# 交换器名称
mq.config.exchange=log.direct
# info级别queue的名称
mq.config.queue.info=log.info
# info级别的路由键
mq.config.queue.info.routing.key=log.info.routing.key
# error级别queue的名称
mq.config.queue.error=log.error
# error级别的路由键
mq.config.queue.error.routing.key=log.error.routing.key

Topic交换器
主题交换器，也称为规则匹配交换器。是通过自定义的模糊匹配规则来决定消息存储在哪些队列中。当Producer发送消息到RabbitMQ中时，MQ中的交换器会根据路由键来决定消息应该发送到哪些队列中。Consumer同样是注册一个监听器到队列，监听队列状态，当队列状态发生变化时，消费消息。注册监听器需要提供交换器信息，队列信息和路由键信息。

Fanout交换器
广播交换器。这种交换器会将接收到的消息发送给绑定的所有队列中。当Producer发送消息到RabbitMQ时，交换器会将消息发送到已绑定的所有队列中，这个过程交换器不会尝试匹配路由键，所以消息中不需要提供路由键信息。Consumer仍旧注册监听器到队列，监听队列状态，当队列状态发生变化，消费消息。注册监听器需要提供交换器信息和队列信息。

RabbitMQ消息可靠性处理
前面内容，如果consumer未启动，而producer发送了消息。则消息会丢失。
如果consumer先启动，创建queue后，producer发送消息可以正常消费。那么当所有的consumer宕机的时候，queue会auto-delete，消息仍旧会丢失。
这种情况，消息不可靠。有丢失的可能。
Rabbitmq的消息可靠性处理，分为两部分。
1 - 消息不丢失。当consumer全部宕机后，消息不能丢失。 持久化解决
2 - 消息不会错误消费。当consumer获取消息后，万一consumer在消费消息的过程中发生了异常，如果rabbitmq一旦发送消息给consumer后立刻删除消息，也会有消息丢失的可能。 确认机制解决

消息持久化
@Queue注解中的属性 - autoDelete：当所有消费客户端连接断开后，是否自动删除队列 。true：删除 false：不删除
@Exchange注解中的属性 - autoDelete：当交换器所有的绑定队列都不再使用时，是否自动删除交换器。true：删除 false：不删除

消息确认机制 ACK - acknowledge
什么是消息确认机制？
如果在消息处理过程中，消费者的服务器在处理消息时发生异常，那么这条正在处理的消息就很可能没有完成消息的消费，如果RabbitMQ在Consumer消费消息后立刻删除消息，则可能造成数据丢失。为了保证数据的可靠性，RabbitMQ引入了消息确认机制。
消息确认机制是消费者Consumer从RabbitMQ中收到消息并处理完成后，反馈给RabbitMQ的，当RabbitMQ收到确认反馈后才会将此消息从队列中删除。
如果某Consumer在处理消息时出现了网络不稳定，服务器异常等现象时，那么就不会有消息确认反馈，RabbitMQ会认为这个消息没有正常消费，会将消息重新放入队列中。
如果在Consumer集群环境下，RabbitMQ未接收到Consumer的确认消息时，会立即将这个消息推送给集群中的其他Consumer，保证不丢失消息。
如果Consumer没有确认反馈，RabbitMQ将永久保存消息。
消息确认机制默认都是开启状态的，同时不推荐关闭消息确认机制。

注意：如果Consumer没有处理消息确认，将导致严重后果。如：所有的Consumer都没有正常反馈确认信息，并退出监听状态，消息则会永久保存，并处于锁定状态，直到消息被正常消费为止。消息的发送者Producer如果持续发送消息到RabbitMQ，那么消息将会堆积，持续占用RabbitMQ所在服务器的内存，导致“内存泄漏”问题。

消息确认机制处理方案：
编码异常处理（推荐）
通过编码处理异常的方式，保证消息确认机制正常执行。这种处理方案也可以有效避免消息的重复消费。
异常处理，不是让Consumer编码catch异常后，直接丢弃消息，或反馈ACK确认消息。而是做异常处理的。该抛的异常，还得抛，保证ACK机制的正常执行。或者使用其他的手法，实现消息的再次处理。如：catch代码块中，将未处理成功的消息，重新发送给MQ。如：catch代码中，本地逻辑的重试（使用定时线程池重复执行任务3次。）

配置重试次数处理
通常来说，消息重试3次以上未处理成功，就是Consumer开发出现了严重问题。需要修改Consumer代码，提升版本/打补丁之类的处理方案。
通过全局配置文件，开启消息消费重试机制，配置重试次数。当RabbitMQ未收到Consumer的确认反馈时，会根据配置来决定重试推送消息的次数，当重试次数使用完毕，无论是否收到确认反馈，RabbitMQ都会删除消息，避免内存泄漏的可能。具体配置如下：

#开启重试
spring.rabbitmq.listener.retry.enabled=true
#重试次数，默认为3次
spring.rabbitmq.listener.retry.max-attempts=5

常用MQ产品对比和选择
社区活跃度：RabbitMQ > ActiveMQ = RocketMQ > kafka
消息持久化：RabbitMQ、ActiveMQ、RocketMQ、kafka都支持持久化。ZeroMQ不支持持久化。
高并发： RabbitMQ = kafka > RocketMQ > ActiveMQ。RabbitMQ高并发是基于ErLang的。ErLang本身就是针对高并发提供的一种开发脚本语言。
吞吐量：RabbitMQ = kafka > RocketMQ > ActiveMQ。小型项目（并发吞吐低于万级别）使用ActiveMQ。中型项目（并发吞吐10万~100万级），可选RocketMQ、ActiveMQ。大型项目优先考虑RabbitMQ和Kafka。
综合技术：RabbitMQ和kafka最好。RocketMQ次之。ActiveMQ最弱。如：可靠性、路由、集群、事务、高可用队列、消息可靠排序、持久化、可视化管理工具等。
RabbitMQ和Kafka选择：建议Kafka针对日志处理。其他使用RabbitMQ。商业项目中，如果现有的系统架构已经使用了某一个MQ产品，且没有业务和性能上的问题，不推荐切换MQ产品。