RabbitMQ入门
概念介绍
RabbitMQ整体上可以看做是一个生产者和消费者模型，主要负责接收、存储和转发消息。
生产者和消费者
Producer：生产者，就是投递消息的一方。
生产者创建消息，然后发布到RabbitMQ中，消息一般可以包含两个部分：消息体和标签（Label）。消息体也可以称之为payload，在实际的应用中，消息体一般是一个带有业务逻辑结构的数据，比如一个Json字符串；消息的标签用来表述这条消息，比如一个交换器的名称和一个路由键。生产者把消息交由RabbitMQ，RabbitMQ之后会根据标签把消息发送给感兴趣的消费者。
Consumer：消费者，就是接收消息的一方。
消费者连接到RabbitMQ服务器，并订阅到队列上。当消费者消费一条消息时，只消费消息的消息体（payload）。在消息路由的过程中，消息的标签会丢弃，存入到队列中的消息只有消息体，消费者也只会消费消息体，也不知道消息的生产者是谁，当然消费者也不需要知道。
Broker：消息中间件的服务节点。
对于RabbitMQ来说，一个RabbitMQ Broker可以简单的看作一个RabbitMQ服务节点或者RabbitMQ服务实例。大多数的情况下可以将一个RabbitMQ Broker看作一台RabbitMQ服务器。
下图展示了生产者将消息存入RabbitMQ Broker，以及消费者从Broker中消费数据的整个流程：
对上图的流程进行简单的说明：
首先是生产者将业务方的数据进行可能的包装，之后封装成消息，发送到Broker中。订阅者订阅并接收消息，经过可能的解包处理得到原始的数据，之后再进行业务处理逻辑。这个业务处理逻辑并不一定需要和接收消息的逻辑使用同一个线程。消费者进程可以使用一个线程去接收消息，存入到内存中，而业务处理逻辑使用另外一个线程去读取数据，这样的话可以将消息的处理进一步的解耦，提高整个应用的处理效率。
队列
Queue：队列，是RabbitMQ的内部对象，用于存储消息。如下图2-3所示
多个消费者可以订阅同一个队列，这时队列中的消息会被平分到（轮询）给多个消费者处理，而不是每个消费者都收到所有的消息并处理。如下图2-4所示
交换器
Exchange：交换器。RabbitMQ中生产者将消息发送到Exchange（交换器，通常用大写的X表示），由交换器将消息路由到一个或者多个队列中。如果路由不到，或许会返回给生产者，或者直接丢弃。
路由键
RoutingKey：路由键。生产者将消息发送给交换器的时候，一般会指定一个RoutingKey，用来指定这个消息的路由规则，而这个RoutingKey需要与交换器类型和绑定键（BindingKey）联合使用才能最终生效。
绑定
Binding：绑定。RabbitMQ中通过绑定将交换器与队列关联起来，在绑定的时候一般会指定一个绑定键，这样RabbitMQ就知道如何正确的将消息路由到队列了。如下图2-6所示
生产者将消息发送给交换器时，需要一个RoutingKey，当BindingKey和RoutingKey相匹配时，消息就会被路由到对应的队列中。在绑定多个队列到同一个交换器的时候，这些绑定允许使用相同的BindingKey。BindingKey并不是在所有的情况下都有效，它依赖于交换器的类型，比如fanout类型就会无视BindingKey，而是将消息路由到所有绑定到该交换器的队列中。
交换器类型
RabbitMQ常用的交换器类型有fanout、direct、topic、headers这四种。AMQP协议里还提到另外两种类型：System和自定义，这里不予描述。
fanout
它会把所有发送到该交换器的消息路由到所有与该交换器绑定的队列中。
direct
direct类型的交换器路由规则很简单，它会把消息路由到那些BindingKey和RoutingKey完全匹配的队列中。
以下图2-7为例，交换器的类型为direct，如果我们发送一条消息，并在发送消息的时候设置路由键为“warning”，则消息会路由到Queue1和Queue2：
如果在发送消息的时候将路由键设置为“info”或者“debug”，消息只会路由到Queue2中，如果以其他的路由键发送消息，则消息不会路由到这两个队列之中。
topic
topic类型的交换器在direct的匹配规则上进行了扩展，与direct类型的相似，也是将BindingKey和RoutingKey相匹配的队列中，但是这里的匹配规则有些不同，它约定：
❤ RoutingKey为一个点号“.”分隔的字符串（被点号“.”分隔开的每一段独立的字符串称为一个单词），如“com.rabbitmq.client”、“java.util.concurrent”、“com.hidden.client”；
❤ BindingKey 和 RoutingKey一样也是点号“.”分隔开的字符串；
❤ BindingKey中可以存在两种特殊的字符串“*”和“#”，用于模糊匹配，其中“*”用于匹配一个单词。“#”用于匹配多个单词（可以是零个）；
以图2-8 中的配置为例:
- 路由键为" com.rabbitmq.client" 的消息会同时路由到Queuel 和Queue2;
- 路由键为" com.hidden.client" 的消息只会路由到Queue2 中:
- 路由键为" com.hidden.demo" 的消息只会路由到Queue2 中:
- 路由键为"java.rabbitmq.demo" 的消息只会路由到Queuel 中:
- 路由键为" java.util..concurrent" 的消息将会被丢弃或者返回给生产者(需要设置mandatory参数），因为它每一匹配任何路由键。
headers
headers类型的交换器不依赖于路由键的匹配规则来路由消息，而是根据发送的消息内容中的headers属性进行匹配。在绑定队列和交换器时制定一组键值对，当发送消息到交换器时，RabbitMQ会获取到该消息的headers（也是一组键值对的形式），对比其中的键值对是否完全匹配队列和交换器绑定时指定的键值对，如果完全匹配则消息会路由到该队列，否则不会路由到该队列。headers类型的交换器性能会很差，而且也不实用，基本上不会看到它的存在。
RabbitMQ运转流程
生产者发送消息的过程
（1）生产者连接到RabbitMQ Broker，建立一个连接（Connection），开启一个信道（Channel）；
（2）生产者声明一个交换器，并设置相关属性，比如交换器的类型、是否持久化等；
（3）生产者声明一个队列并设置相关的属性，比如是否排他、是否持久化、是否自动删除等；
（4）生产者通过路由键将交换器和队列绑定起来；
（5）生产者发送消息至RabbitMQ Broker，其中包含路由键、交换器等信息；
（6）相应的交换器根据接收到的路由键查找相匹配的队列；
（7）如果找到，则将从生产者发送过来的消息存入到相应的队列中；
（8）如果没有找到，则根据生产者的配置属性选择丢弃还是退回给生产者；
（9）关闭信道；
（10）关闭连接。
消费者接收消息的过程
（1）消费者连接到RabbitMQ Broker，建立一个连接，开启一个信道；
（2）消费者向RabbitMQ Broker请求消费相应队列中的消息，可能会设置相应的回调函数，以及做一些准备工作；
（3）等待RabbitMQ Broker回应并投递相应队列中的消息，消费者接收消息；
（4）消费者确认接收到的消息；
（5）RabbitMQ从队列中删除相应的已经被确认的消息；
（6）关闭信道；
（7）关闭连接。
在上述生产者和消费者的过程中都涉及到了连接和信道。
Connection 和 Channel
Connection：一条TCP连接。
Channel：建立在Connection之上的虚拟连接，RabbitMQ处理的每条AMQP指令都是通过Channel完成的。
上图2-9展示了Connection和Channel的关系。
但是有一个疑问，我们完全可以使用Connection就能完成信道的工作，为什么还要引入信道呢？
想一个这样的场景，一个应用程序有很多个线程需要从RabbitMQ中消费消息，或者生产消息，那么必然需要建立很多个Connection，也就是很多个TCP连接。然而对于操作系统而言，建立和销毁TCP连接是非常昂贵的开销，如果遇到使用高峰，性能瓶颈也随之显现。RabbitMQ采用NIO的做法，选择TCP连接复用，不仅可以减少性能开销，同时也便于管理。
每个线程把持一个信道，所以信道复用了Connection的TCP连接。同时RabbitMQ可以确保每个线程的私密性，就像拥有独立的连接一样。当每个信道的流量不是很大时，复用单一的Connection可以在产生性能瓶颈的情况下有效的节省TCP连接资源。但是当信道本身的流量很大时，这时候多个信道复用一个Connection就会产生性能瓶颈，进而使得整体的流量被限制了，此时就需要开辟多个Connection，将这些信道均摊到这些Connection中。
参考：《RabbitMQ实战指南》 朱忠华 编著：
