一、RabbitMQ 核心概念
1.1 整体结构
RabbitMQ 由以下几部分构成：
- broker （服务器节点）
- virtual host (虚拟主机：各个虚拟主机之间是相互隔离的，哪怕使用同样的队列名称！)
- connection （连接：发送接收消息都需要与RabbitMQ建立连接，通常我们会保持一个长连接）
- channel （信道：一个连接包含多个信道，每次使用后可以关闭信道。是建立在connection上的一个轻量级连接，大部分操作都是通过channel完成）
- Exechange （交换机：高级特性的起点，控制消息的分发机制，通过RoutingKey实现）
- bind （交换机与队列的绑定关系，通过RouteKey来绑定）
- queue (队列：存储消息)
1.2 消息分发机制（Exechange）
交换机一共有四种支持类型：direct、fanout、topic、headers。以及一个默认类型：default。
一个交换机下可以创建多个队列，再发送消息时，通过RoutingKey来判定发送给哪些队列。没有什么是加一层解决不了的问题。可以理解为交换机为了实现广播、模糊匹配等消息分发需求，增加了交换机这一层来实现发送机制。如果没有这次层，可能我们在发送时就需要自己处理发送逻辑，循环判断！
1.2.1 default
默认交换机类型。消息发送时可以不需要配置交换机直接配置要发送的队列名称。相当于跳过交换机，直接指定队列，无需RouteKey。
1.2.2 direct
直连交换机类型。可以通过完整的RoutingKey匹配到一个指定队列。类似于Equals
1.2.3 fanout
广播交换机。发送给该交换机的消息，会广播给所有绑定队列。无需考虑RoutingKey！！！。
1.2.4 topic
主题交换机，实现了模糊匹配，更加的灵活。可以通过【#、* 】来定义模糊匹配规则。#号代表全匹配，代表匹配一组单词（com.abc.efg）分为了三组单词，.abc、.efg无法匹配，.abc.*、#.efg可以匹配。
1.2.5 headers
类似于direct，都是完全匹配。这里需要先解释一下header，可以理解为http的请求头，其中不仅包含固定的RoutingKey，还可以自定义其他数据。headers不匹配RoutingKey，而是匹配设定好的header条件比如X= 1。headers一般不建议使用。（性能问题）
1.3 AMQP协议流转过程
RabbitMQ 高可用集群
RabbitMQ 集群通过同步数据方式实现。目前有两种集群方式 Cluster 和 镜像模式。
Cluster
Cluster 集群主要通过同步元数据的形式实现。
元数据主要包括：
- 队列元数据：队列名称及属性
- 交换机：交换机的名称及属性
- 绑定关系元数据：交换机与队列绑定关系
- vhost元数据：
通过元数据同步方式实现会存在一个问题，假如现在Rabbit01挂掉了，由于只做了元数据同步，队列内容仍在Rabbit01节点中存储，所以消费者仍然无法通过Rabbit02节点拿到数据。
使用这种集群方式可以提升可用性，但无法保证完全可用。性能相对镜像模式要高，因为同步内容少。
镜像
镜像模式会同步队列内容。
性能相对于Cluster来讲要低，可用性要高很多。内存占用量过大。类似于主从模式。
备注：没有重复消费问题，除非一次监听多个节点。
