概念：
Broker：接收和分发消息的应用，RabbitMQ Server就是Message Broker
Connection： publisher / consumer和 broker之间的TCP连接
Channel：如果每一次访问RabbitMQ都建立一个Connection，在消息量大的时候建立TCP
Connection的开销将是巨大的，效率也较低。Channel是在connection 内部建立的逻辑连接，如果应用程序支持多线程，通常每个thread创建单独的channel进行通讯，AMQP method包含了channel id 帮助客户端和message broker识别 channel，所以channel 之间是完全隔离的。Channel作为轻量级的Connection极大减少了操作系统建TCP connection的开销
Exchange：message 到达 broker 的第一站，根据分发规则，匹配查询表中的 routing key，分发消息到queue 中去。常用的类型有: direct (point-to-point), topic(publish-subscribe) and fanout
(multicast)
Routing Key：生产者将消息发送到交换机时会携带一个key,来指定路由规则
binding Key：在绑定Exchange和Queue时，会指定一个BindingKey,生产者发送消息携带的RoutingKey会和bindingKey对比，若一致就将消息分发至这个队列
vHost 虚拟主机：每一个RabbitMQ服务器可以开设多个虚拟主机每一个vhost本质上是一个mini版的RabbitMQ服务器，拥有自己的 "交换机exchange、绑定Binding、队列Queue"，更重要的是每一个vhost拥有独立的权限机制，这样就能安全地使用一个RabbitMQ服务器来服务多个应用程序，其中每个vhost服务一个应用程序。
工作模式
五种常用模式
1.simple (简单模式)
一个消费者消费一个生产者生产的信息
2.Work queues(工作模式)
一个生产者生产信息，多个消费者进行消费，但是一条消息只能消费一次
3.Publish/Subscribe（发布订阅模式）
生产者首先投递消息到交换机，订阅了这个交换机的队列就会收到生产者投递的消息
4.Routing（路由模式）
生产者生产消息投递到direct交换机中，扇出交换机会根据消息携带的routing Key匹配相应的队列
5.Topics（主题模式）
生产者生产消息投递到topic交换机中，上面是完全匹配路由键，而主题模式是模糊匹配，只要有合适规则的路由就会投递给消费者
保证消息的稳定性
消息持久化
RabbitMQ的消息默认存在内存中的，一旦服务器意外挂掉，消息就会丢失
消息持久化需做到三点
Exchange设置持久化
Queue设置持久化
Message持久化发送：发送消息设置发送模式deliveryMode=2，代表持久化消息
ACK确认机制
多个消费者同时收取消息，收取消息到一半，突然某个消费者挂掉，要保证此条消息不丢失，就需要acknowledgement机制，就是消费者消费完要通知服务端，服务端才将数据删除
这样就解决了，及时一个消费者出了问题，没有同步消息给服务端，还有其他的消费端去消费，保证了消息不丢的case。
设置集群镜像模式
我们先来介绍下RabbitMQ三种部署模式：
1）单节点模式：最简单的情况，非集群模式，节点挂了，消息就不能用了。业务可能瘫痪，只能等待。
2）普通模式：默认的集群模式，某个节点挂了，该节点上的消息不能用，有影响的业务瘫痪，只能等待节点恢复重启可用（必须持久化消息情况下）。
3）镜像模式：把需要的队列做成镜像队列，存在于多个节点，属于RabbitMQ的HA方案
为什么设置镜像模式集群，因为队列的内容仅仅存在某一个节点上面，不会存在所有节点上面，所有节点仅仅存放消息结构和元数据。
消息发送失败补偿方案
消息发送失败处理方案
场景一：消息找不到队列导致消息发送失败。
设置mandatory=true
当mandatory参数设为true时，交换器无法根据自身的类型和路由键找到一个符合条件的队列的话，那么RabbitMQ会调用Basic.Return命令将消息返回给生产者。
这时候可以通过调用channel.addReturnListener来添加ReturnListener监听器实现。- channel.basicPublish("EXCHANGE_NAME", "", true, MessageProperties.PERSISTENT_TEXT_PLAIN, "text".getBytes());
- channel.addReturnListener(new ReturnListener() {
- @Override
- public void handleReturn(int replyCode, String replyText, String exchange, String routingKey, AMQP.BasicProperties basicProperties, byte[] body) throws IOException {
- String message = new String(body);
- System.out.println("返回结果是:" + message);
- }
- });
在通过channel.txSelect方法开启事务之后，我们便可以发布消息给RabbitMQ了，如果事务提交成功，则消息一定到达了RabbitMQ中，如果在事务提交执行之前由于RabbitMQ异常崩溃或者其他原因抛出异常，这个时候我们便可以将其捕获，进而通过执行channel.txRollback方法来实现事务回滚。
缺点：只有消息成功被RabbitMQ接收，事务才能提交成功，否则我们便可在捕获异常之后进行事务回滚，与此同时可以进行消息重发。但是使用事务机制的话会“吸干”RabbitMQ的性能。
- 方案二：生产者将信道设置成confirm（确认）模式
一旦信道进入confirm模式，所有在该信道上面发布的消息都会被指派一个唯一的ID（从1开始），一旦消息被投递到所有匹配的队列之后，RabbitMQ就会发送一个确认（Basic.Ack）给生产者（包含消息的唯一ID），这就使得生产者知晓消息已经正确到达了目的地了。RabbitMQ回传给生产者的确认消息中的deliveryTag包含了确认消息的序号，此外RabbitMQ也可以设置channel.basicAck方法中的multiple参数，表示到这个序号之前的所有消息都已经得到了处理。
消息发送失败补偿方案
当消息发送失败后，结合MQ配置，对消息进行重试并记录error日志，达到重试次数后，将处理结果通过回调接口的方式告诉生产者，生产者去进行额外的补偿机制。
confirm方案对比
客户端实现生产者confirm有三种方式：
普通confirm模式：每发送一条消息后，调用waitForConfirms()方法，等待服务器端confirm。实际上是一种串行confirm了。
批量confirm模式：每发送一批消息后，调用waitForConfirms()方法，等待服务器端confirm。
异步confirm模式：提供一个回调方法，服务端confirm了一条或者多条消息后Client端会回调这个方
注意：
批量模式极大提升confirm效率，但是问题在于一旦出现confirm返回false或者超时的情况时，客户端需要将这一批次的消息全部重发，这会带来明显的重复消息数量，并且，当消息经常丢失时，批量confirm性能应该是不升反降的。
消息消费失败处理方案
设置死信队列
当消息发送失败后，设置requeue=false消息进入死信队列，并获取死信队列的长度，设置重新发送到正常队列的重试时间和重试间隔，重新发送到正常队列。
监控死信队列长度，日志记录及时预警。
实现延迟队列
RabbitMQ本身没有延迟队列，需要靠TTL和DLX模拟出延迟的效果
TTL来设置一个消息的的过期时间，DLX设置一个死信队列，将过期的消息推送到死信队列中，消费端监听死信队列来消费数据，从而达到消息延迟的效果。
死信队列补偿机制
当消息消费失败后，进入死信队列，框架层实现逻辑，获取对应死信队列的消息长度，当大于0时并判断是否超过重试次数并达到重试间隔。当没有超过重试次数时，自动将消息从死信队列迁移到正常队列。
消息防堆积方案
<ul>加强对不合理使用MQ的审批。
监控消费能力(耗时 |
