RabbitMQ 学习系列2 入门上(相关概念: 队列、交换机、路由键、消息生产和消费流程）

2.1 相关概念介绍

　　RabbitMQ整体上是一个生产者与消费者模型，主要负责接收，存储和转发消息。Rabbitmq好比邮局、邮箱和邮递员组成的一个系统，从计算机术语层面来说，rabbitmq模型更像一个交换机模型。

　　　　感悟：对于消费者来说，只需要操作队列，从队列中消费，不需要去创建队列，交换机，路由键等。要创建属于生产者或者是后台系统来配置，在实际生产环境中一般都是通过后台系统来配置，在业务代码端生产者和消费者都不需要创建。

　　2.1.1 生产者和消费者　　　　

　　　　Producer：生产者，投递消息的一方。消息一般可以包含2个部分：消息体和标签(label)。消息体也可以称之为payload，在实际应用中，消息体一般是一个带有业务逻辑结构的数据，比如一个josn字符串。消息的标签用来表述这条消息，比如一个交换器的名称和一个路由键。生产都把消息交由rabbitmq，rabbitmq之后会根据标签把消息发送给感兴趣的消费者(consumer)。

　　　　Consumer：消费者，接收消息一方。消费者连接到rabbitmq服务器，并订阅到队列上。当消费者消费一条消息时，只是消费的消息体(payload)。在消息路由的过程中，消息的标签会丢弃，存入到队列中的消息只有消息体，也就是不知道消息的生产者是谁，当然消息费都不需要知道。

　　　　Broker: 消息中间件的服务节点。一个rabbitmq Broker可以简单地看作一个rabbitmq 服务节点或者rabbitmq 服务实例。

　　　　下面展示了生产者将消息存入rabbitmq Broker，以及消费者从Broker中消费数据的整个流程：

　　　　首先生产者将业务数据进行包装封装成消息，发送(AMQP 协议里这个动作对应的命令为Basic.Publish)到Broker中。消费者订阅并接收消息(AMQP协议里这个动作对应的命令为Basic.Consume或者Basic.Get)，经过解包处理得到原始的数据。

　　2.1.2队列　　　　

　　　　Queue：队列，是rabbitmq的内部对象，用于存储消息. Rabbitmq中消息都只能存储在队列中，这一点和kafka这种消息中间件相反，kafka将消息存储在topic主题这个逻辑层面。
　　　　多个消费者可以订阅同一个队列，这时队列中的消息会被平均分摊(round-robin 即轮询)给多个消费者进行处理，而不是每个消费者都收到所有的消息并处理。
　　　　Rabbitmq不支持队列层面的广播消费，如果需要广播消费，需要在其上进行二次开发，处理逻辑会变得异常复杂，同进也不建议这么做。

　　2.1.3交换器、路由键、绑定

　　　　Exchange：交换器，生产者将消息发送到Exchange(通常也可以大写X 来表示)，由交换器将消息路由到一个或者多个队列中，如果路由不到，或许会返回给生产者或者直接丢弃。这里可能将rabbitmq中的交换器看作一个简单的实体，后面会说。
　　　　RoutingKey：路由键。生产者将消息发给交换器的时候，一般会指定一个RoutingKey,用来指定这个消息的路由规则，而这个RoutingKey需要与交换器类型和绑定键(BindingKey)联合使用才能最终生效。
　　　　Binding：绑定。 rabbitmq中通过绑定将交换器与队列关联起来，在绑定的时候一般会指定一个绑定键(BindingKey),这样rabbitmq就知道如何正确地将消息路由到队列了。

　　　　生产者将消息发送给交换器时，需要一个RoutingKey,当BindingKey和RoutingKey相匹配时，消息会被路由到对应队列中。在绑定多个队列到同一个交换器的时候，这些绑定允许使用相同的BindingKey。
下面以比喻来加深这几个概念的理解。Exchange相当于投递包裹的邮箱，RoutingKey相当于填写在包裹上的地址，BindingKey相当于包裹的目的地。

　　　　在经验的读者可能会发现，在某些情况下,routingkey与Bindingkey可以看作同一个东西，看下面的代码：

　　　　以上代码声明一个direct类型的交换器，然后将交换器和队列绑定起来。channel.queueBind和channel.basicPublish方法同样使用了routingkey。这样做的潜台词是：这里routingkey和Bindingkey是同一个东西，在direct交换器类型下，routingkey和Bindingkey需要完全匹配才能使用。
　　　　但是在topic交换器类型下，routingkey和Bindingkey之间需要做模糊匹配，两者并不是相同的。
　　　　大多数情况下习惯性地将Bindingkey写成routingkey，尤其是在使用direct类型的交换器的时候。本文后面的篇幅中也会将两者合称为路由键。

　　感悟:当交换机为direct类型时，routingkey和Bindingkey是同一个东西，因为在direct交换器类型下，routingkey和Bindingkey需要完全匹配才能使用。当 topic类型时，routingkey和Bindingkey之间需要做模糊匹配。只针对生产者生产消息选择存储队列有关。

　　2.1.4交换器类型

　　　　Rabbitmq常用的交换器类型有fanout、direct、topic、headers这四种。AMQP协议里还提到另外两种类型:system和自定义，这里不予描述。
　　　　 (1) fanout: 它会把所有发送到该交换器的消息路由到所有与该交换器绑定的队列中。
　　　　 (2) direct：它会把消息路由到那些BindingKey与RoutingKey完全匹配的队列中。

　　　　(3)Topic
　　　　　　前面讲到direct类型的交换器路由规则是完全匹配BindingKey与RoutingKey. 但是这种严格的匹配方式在很多情况下不能满足实际业务的需求。topic类型的交换器在匹配规则上进行了扩展，它与direct类型的交换器相似，也是将消息路由到BindingKey与RoutingKey相匹配的队列中，但这里的匹配规则有些不同，它约定:
　　　　　　RoutingKey为一个点号”.”分隔的字符串(被点号”.”分隔开的每一段独立的字符串称为一个单词)如 com.rabbitmq.client
　　　　　　Bindingkey和RoutingKey一样也是点号”.”分隔的字符串
　　　　　　Bindingkey中可以存在两种特殊字符串”*”和”#”，用于做模糊匹配，其中”*”用于匹配一个单词，”#”用于匹配多规格单词(可以是零个)

　　　　(4)headers
　　　　　　headers类型的交换器不依赖于路由键的匹配规则来路由消息，而是根据发送的消息内容中的headers属性进行匹配，在绑定队列和交换器时制定一组键值对，当发送消息到交换器时，rabbitmq会获取到该消息的headers（也是一个键值对的形式），对比其中的键值是否完全匹配队列和交换器绑定时指定的键值对，如果完全匹配则消息会路由到该队列，否则不会路由到该队列。Headers类型的交换器性能会很差，而且不实用，基本不会看到它的存在。

　　2.15 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.关闭连接

　　　　这里又引入了两个新的概念，Connection和Channel。无论是生产者还是消费者，都需要和RabbitMQ Broker建立连接，这个连接就是一条TCP连接，也就是Connection。一但TCP连接建立起来，客户端紧接着可以创建一个AMQP信道(Channel)，每个信道都会被指派一个唯一的ID。信道是建立在Connection之上的虚拟连接，RabbitMQ 处理的每条AMQP指令都是通过信道完成的。

　　　　我们完全可能直接使用Connection就能完成信息的工作，为什么还要引入信道，试想这样一个场景，一个应用程序中有很多个线程需要从RabbitMQ中消费消息或者生产消息，那么必然需要建立很多个Conection，也就是许多个TCP连接，然而对于操作系统而言，建立和销毁TCP连接是非常昂贵的开销，如果遇到使用高峰，性能瓶颈也随之显现。RabbitMQ采用类似NIO(Non-blocking I/O 非阻塞I/O)的做法，选择TCP连接复用，不仅可以减少性能开销，同时也便于管理。

　　　　每个线程把持一个信道，所以信道复用了Connection的tcp连接。当每个信道流量不是很大时，复用单一的Connection可以在产生性能瓶颈的情况下有效地节省TCP连接资源，但是当信道本身的流量很大时，这时候复用一个Connection就会产生性能瓶颈，进而使整体的流量被限制了，此时就需要开廦多个Connection,将这些信道均摊到这些Connection中.