.Net RabbitMQ实战指南——RabbitMQ相关概念介绍
什么是消息中间件
消息（Message）是指在应用间传送的数据。消息可以非常简单，比如只包含文本字符串、JSON等，也可以很复杂，比如内嵌对象。
消息队列中间件（Message Queue Middleware，简称为MQ）是指利用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可以在分布式环境下扩展进程间的通信。
面向消息的中间件（简称为MOM，Message Oriented Middleware）提供了以松散耦合的灵活方式集成应用程序的一种机制。它们提供了基于存储和转发的应用程序之间的异步数据发送，即应用程序彼此不直接通信，而是与作为中介的消息中间件通信。消息中间件提供了有保证的消息发送，应用程序开发人员无须了解远程过程调用（RPC）和网络通信协议的细节。
举例说明，应用程序A与应用程序B通过使用消息中间件的应用程序编程接口（API，Application Program Interface）发送消息来进行通信。
消息中间件的作用
消息中间件凭借其独到的特性，在不同的应用场景下可以展现不同的作用。
解耦：消息中间件在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口，这允许你独立地扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束即可。
冗余（存储）：消息中间件可以把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。在把一个消息从消息中间件中删除之前，需要你的处理系统明确地指出该消息已经被处理完成，从而确保你的数据被安全地保存直到你使用完毕。
扩展性：因为消息中间件解耦了应用的处理过程，所以提高消息入队和处理的效率是很容易的，只要另外增加处理过程即可，不需要改变代码，也不需要调节参数。
削峰：在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见。使用消息中间件能够使关键组件支撑突发访问压力，不会因为突发的超负荷请求而完全崩溃。
可恢复性：消息中间件降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入消息中间件中的消息仍然可以在系统恢复后进行处理。
顺序保证：在大多数使用场景下，数据处理的顺序很重要，大部分消息中间件支持一定程度上的顺序性。
缓冲：在任何重要的系统中，都会存在需要不同处理时间的元素。消息中间件通过一个缓冲层来帮助任务最高效率地执行，写入消息中间件的处理会尽可能快速。该缓冲层有助于控制和优化数据流经过系统的速度。
异步通信：在很多时候应用不想也不需要立即处理消息。消息中间件提供了异步处理机制，允许应用把一些消息放入消息中间件中，但并不立即处理它，在之后需要的时候再慢慢处理。
RabbitMQ相关介绍
RabbitMQ整体上是一个生产者与消费者模型，主要负责接收、存储和转发消息。
RabbitMQ的整体模型架构如图
Producer：生产者
生产者创建消息，然后发布到RabbitMQ中。消息一般可以包含2个部分：消息体和标签（Label）。消息体也可以称之为payload，在实际应用中，消息体一般是一个带有业务逻辑结构的数据，比如一个JSON字符串。当然可以进一步对这个消息体进行序列化操作。消息的标签用来表述这条消息，比如一个交换器的名称和一个路由键。
Consumer：消费者
消费者连接到RabbitMQ服务器，并订阅到队列上。当消费者消费一条消息时，只是消费消息的消息体（payload）。在消息路由的过程中，消息的标签会丢弃，存入到队列中的消息只有消息体，也就不知道消息的生产者是谁。
Broker：消息中间件的服务节点
对于RabbitMQ来说，一个RabbitMQ Broker可以简单地看作一个RabbitMQ服务节点，或者RabbitMQ服务实例。大多数情况下也可以将一个RabbitMQ Broker看作一台RabbitMQ服务器。
消息队列的运转过程如图
Queue：队列，是RabbitMQ的内部对象，用于存储消息
RabbitMQ中消息都只能存储在队列中，多个消费者可以订阅同一个队列，这时队列中的消息会被平均分摊（Round-Robin，即轮询）给多个消费者进行处理，而不是每个消费者都收到所有的消息并处理，如图
Exchange：交换器
RabbitMQ中生产者将消息发送到Exchange（交换器，通常也可以用大写的“X”来表示），由交换器将消息路由到一个或者多个队列中。如果路由不到，或许会返回给生产者，或许直接丢弃。
RabbitMQ常用的交换器类型有fanout、direct、topic、headers四种
fanout
把所有发送到该交换器的消息路由到所有与该交换器绑定的队列中
direct
把消息路由到那些BindingKey和RoutingKey完全匹配的队列中。如图，交换器的类型为direct，如果我们发送一条消息，并在发送消息的时候设置路由键为“warning”，则消息会路由到Queue1和Queue2
topic
topic类型的交换器在匹配规则上进行了扩展，它与direct类型的交换器相似，也是将消息路由到BindingKey和RoutingKey相匹配的队列中，不同的是topic支持模糊匹配。BindingKey中可以存在两种特殊字符串“*”和“＃”，用于做模糊匹配，其中“*”用于匹配一个单词，“＃”用于匹配多个单词（可以是零个）。
●路由键为“com.rabbitmq.client”的消息会同时路由到Queue1和Queue2；
●路由键为“com.hidden.client”的消息只会路由到Queue2中；
●路由键为“com.hidden.demo”的消息只会路由到Queue2中；
●路由键为“java.rabbitmq.demo”的消息只会路由到Queue1中；
●路由键为“java.util.concurrent”的消息将会被丢弃或者返回给生产者（需要设置mandatory参数），因为它没有匹配任何路由键。
headers
headers类型的交换器不依赖于路由键的匹配规则来路由消息，而是根据发送的消息内容中的headers属性进行匹配。在绑定队列和交换器时指定一组键值对，发送消息到交换器时，RabbitMQ会获取到该消息的headers（也是一个键值对的形式），对比其中的键值对是否完全匹配队列和交换器绑定时指定的键值对，如果完全匹配则消息会路由到该队列headers类型的交换器性能会很差，而且也不实用所以很少使用。
RoutingKey：路由键
生产者将消息发给交换器的时候，一般会指定一个RoutingKey，用来指定这个消息的路由规则，而这个Routing Key需要与交换器类型和绑定键（BindingKey）联合使用才能最终生效。
Binding：绑定
RabbitMQ中通过绑定将交换器与队列关联起来，在绑定的时候一般会指定一个绑定键（BindingKey），告诉RabbitMQ如何正确地将消息路由到队列
生产者将消息发送给交换器时，需要一个RoutingKey，当BindingKey和RoutingKey相匹配时，消息会被路由到对应的队列中。在绑定多个队列到同一个交换器的时候，这些绑定允许使用相同的BindingKey。BindingKey并不是在所有的情况下都生效，它依赖于交换器类型，比如fanout类型的交换器就会无视BindingKey，而是将消息路由到所有绑定到该交换器的队列中。
RabbitMQ运转流程
生产者发送消息的过程
（1）生产者连接到RabbitMQ Broker，建立一个连接（Connection），开启一个信道（Channel）。
（2）生产者声明一个交换器，并设置相关属性，比如交换机类型、是否持久化等。
（3）生产者声明一个队列并设置相关属性，比如是否排他、是否持久化、是否自动删除等。
（4）生产者通过路由键将交换器和队列绑定起来。
（5）生产者发送消息至RabbitMQ Broker，其中包含路由键、交换器等信息。
（6）相应的交换器根据接收到的路由键查找相匹配的队列。
（7）如果找到，则将从生产者发送过来的消息存入相应的队列中。
（8）如果没有找到，则根据生产者配置的属性选择丢弃还是回退给生产者。
（9）关闭信道。
（10）关闭连接。
消费者接收消息的过程
（1）消费者连接到RabbitMQ Broker，建立一个连接（Connection），开启一个信道（Channel）。
（2）消费者向RabbitMQ Broker请求消费相应队列中的消息，可能会设置相应的回调函数，以及做一些准备工作。
（3）等待RabbitMQ Broker回应并投递相应队列中的消息，消费者接收消息。
（4）消费者确认（ack）接收到的消息。
（5）RabbitMQ从队列中删除相应已经被确认的消息。
（6）关闭信道。
（7）关闭连接。
无论是生产者还是消费者，都需要和RabbitMQ Broker建立连接，这个连接是一条TCP连接，也就是Connection。一旦TCP连接建立起来，客户端紧接着可以创建一个AMQP信道（Channel），每个信道都会被指派一个唯一的ID。信道是建立在Connection之上的虚拟连接，RabbitMQ处理的每条AMQP指令都是通过信道完成的。
为什么要引入信道?
一个应用程序有很多个线程需要从RabbitMQ中消费消息或者生产消息，建立很多个Connection，也就是多个TCP连接，建立和销毁TCP连接是非常昂贵的开销。RabbitMQ采用类似NIO（Non-blocking I/O）的做法，选择TCP连接复用，不仅减少性能开销，同时也便于管理。每个线程把持一个信道，信道复用了Connection的TCP连接。当每个信道的流量不是很大时，复用单一的Connection可以在产生性能瓶颈的情况下有效地节省TCP连接资源。但是当信道的流量很大时，这时候多个信道复用一个Connection就会产生性能瓶颈，就需要开辟多个Connection，将这些信道均摊到这些Connection中。
