RabbitMQ入门
RabbitMQ简介
AMQP，即Advanced Message Queuing Protocol，高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。消息中间件主要用于组件之间的解耦，消息的发送者无需知道消息使用者的存在，反之亦然。
AMQP的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全。从 AMQP 协议可以看出，Queue、Exchange 和 Binding 构成了 AMQP 协议的核心。
RabbitMQ使用的是AMQP协议，它是一种二进制协议。默认启动端口 5672。
基本概念
Producer（图中画的是publisher,一般我们叫做Producer）：消息生产者，即投递消息的程序。
Broker：消息队列服务器实体
说明：它提供一种传输服务,它的角色就是维护一条从生产者到消费者的路线，保证数据能按照指定的方式进行传输,
Exchange：消息交换机，它指定消息按什么规则，路由到哪个队列。
Binding：绑定，它的作用就是把 Exchange 和 Queue 按照路由规则绑定起来。
Queue：消息队列载体，每个消息都会被投入到一个或多个队列。
Consumer：消息消费者，即接受消息的程序。
Virtual Host：虚拟主机（节点 ）
说明：表示一批交换器、消息队列和相关对象。虚拟主机是共享相同的身份认证和加密环境的独立服务器域。每个 vhost 本质上就是一个 mini 版的 RabbitMQ 服务器，拥有自己的队列、交换器、绑定和权限机制。vhost 是 AMQP 概念的基础，必须在连接时指定，RabbitMQ 默认的 vhost 是 / 。
一、ConnectionFactory、Connection、Channel
ConnectionFactory、Connection、Channel 都是RabbitMQ对外提供的API中最基本的对象。Connection是RabbitMQ的socket链接，它封装了socket协议相关部分逻辑。ConnectionFactory为Connection的制造工厂。
Channel 是我们与RabbitMQ打交道的最重要的一个接口，我们大部分的业务操作是在Channel这个接口中完成的，包括定义Queue、定义Exchange、绑定Queue与Exchange、发布消息等。
下面详细介绍channel(信道) :
消息推送使用的通道，是生产消费者与RabbitMQ通信的渠道。信道是建立在TCP连接上的虚拟连接。它建立在上述的TCP连接中。数据流动都是在Channel中进行的。也就是说，一般情况是程序起始建立TCP连接，第二步就是建立这个Channel。RabbitMQ在一条TCP上建立成百上千个信道来达到多个线程处理，这个TCP被多个线程共享，每个线程对应一个信道，信道在RabbitMQ都有唯一的ID ，保证了信道私有性，对应上唯一的线程使用。
疑问：为什么使用Channel，而不是直接使用TCP连接？
对于系统来说，建立和关闭TCP连接是有代价的，频繁的建立关闭TCP连接对于系统的性能有很大的影响，而且TCP的连接数也有限制，这也限制了系统处理高并发的能力。但是，在TCP连接中建立Channel是没有上述代价的。对于Producer或者Consumer来说，可以并发的使用多个Channel进行Publish或者Receive。有实验表明，1s的数据可以Publish10K的数据包。当然对于不同的硬件环境，不同的数据包大小这个数据肯定不一样，但是，对于普通Consumer或者Producer来说，这已经足够了。
类似概念：TCP是电缆，信道就是里面的光纤，每个光纤都是独立的，互不影响。
二、Queue
Queue（队列）是RabbitMQ的内部对象，用于存储消息，用下图表示。
RabbitMQ中的消息都只能存储在Queue中，生产者（下图中的P）生产消息并最终投递到Queue中，消费者（下图中的C）可以从Queue中获取消息并消费。
多个消费者可以订阅同一个Queue，这时Queue中的消息会被平均分摊给多个消费者进行处理，而不是每个消费者都收到所有的消息并处理。
三、Exchange-交换机
那么为什么我们需要 Exchange 而不是直接将消息发送至队列呢？
AMQP 协议中的核心思想就是生产者和消费者的解耦，生产者从不直接将消息发送给队列。实际的情况是，生产者将消息发送到Exchange（交换器，下图中的X），由Exchange将消息路由到一个或多个Queue中（或者丢弃）。
Exchange 收到消息时，他是如何知道需要发送至哪些 Queue 呢？这里就需要了解 Binding 和 RoutingKey 的概念。
1、RoutingKey
生产者在将消息发送给Exchange的时候，一般会指定一个routing key，来指定这个消息的路由规则，而这个routing key需要与Exchange Type及binding key联合使用才能最终生效。
在Exchange Type与binding key固定的情况下（在正常使用时一般这些内容都是固定配置好的），我们的生产者就可以在发送消息给Exchange时，通过指定routing key来决定消息流向哪里。
RabbitMQ为routing key设定的长度限制为255 bytes。
2、Binding
RabbitMQ中通过Binding将Exchange与Queue关联起来，这样RabbitMQ就知道如何正确地将消息路由到指定的Queue了。
3、Binding Key
在绑定（Binding）Exchange与Queue的同时，一般会指定一个binding key；生产者将消息发送给Exchange时，一般会指定一个routing key；当binding key与routing key相匹配时，消息将会被路由到对应的Queue中。这个将在Exchange Types章节会列举实际的例子加以说明。在绑定多个Queue到同一个Exchange的时候，这些Binding允许使用相同的binding key。
binding key 并不是在所有情况下都生效，它依赖于Exchange Type，比如 fanout 类型的Exchange就会无视binding key，而是将消息路由到所有绑定到该Exchange的Queue。
4、Exchange Types - 交换机类型
RabbitMQ常用的Exchange Type有fanout、direct、topic这三种。
1）fanout - 广播模式
fanout类型的Exchange路由规则非常简单，它会把所有发送到该Exchange的消息路由到所有与它绑定的Queue中，无视binding key。
上图中，生产者（P）发送到Exchange（X）的所有消息都会路由到图中的两个Queue，并最终被两个消费者（C1与C2）消费。
2）Direct - 点对点模式
direct类型的Exchange路由规则也很简单，它会把消息路由到那些binding key与routing key完全匹配的Queue中。
上图中，我们以routingKey=”orange”发送消息到Exchange，则消息会路由到Q1。如果我们以routingKey=”black”或routingKey=”green”来发送消息，则消息只会路由到Q2。如果我们以其他routingKey发送消息，则消息不会路由到这两个Queue中。
3）Topic - 主题模式
前面讲到direct类型的Exchange路由规则是完全匹配binding key与routing key，但这种严格的匹配方式在很多情况下不能满足实际业务需求。topic类型的Exchange在匹配规则上进行了扩展，它与direct类型的Exchage相似，也是将消息路由到binding key与routing key相匹配的Queue中，但这里的匹配规则有些不同，它约定：
routing key为英文句号“. ”分隔的字符串（我们将被英文句号“. ”分隔开的每一段独立的字符串称为一个单词），如“stock.usd.nyse”、“nyse.vmw”、“quick.orange.rabbit”
binding key与routing key一样也是英文句号“. ”分隔的字符串。binding key中可以存在两种特殊字符“*”与“#”，用于做模糊匹配，其中“*”用于匹配一个单词，“#”用于匹配零个或者多个单词
上图中:
routingKey=”quick.orange.rabbit”的消息会路由到Q1、Q2
routingKey=”lazy.orange.fox”的消息会路由到Q1、Q2
routingKey=”lazy.brown.fox”的消息会路由到Q2
routingKey=”lazy.pink.rabbit”的消息会路由到Q2（只会投递给Q2一次，虽然这个routingKey与Q2的两个bindingKey都匹配）
routingKey=”quick.brown.fox”、routingKey=”orange”、routingKey=”quick.orange.male.rabbit”的消息将会被丢弃，因为它们没有匹配任何bindingKey
两种特殊的 Exchange
1）Headers
Headers Exchange 会忽略 RoutingKey 而根据消息中的 Headers 和创建绑定关系时指定的 Arguments 来匹配决定路由到哪些 Queue。
Headers Exchange 的性能比较差，而且 Direct Exchange 完全可以代替它，所以不建议使用。
2）Default
Default Exchange 是一种特殊的 Direct Exchange。当你手动创建一个队列时，后台会自动将这个队列绑定到一个名称为空的 Direct Exchange 上，绑定 RoutingKey 与队列名称相同。有了这个默认的交换机和绑定，使我们只关心队列这一层即可，这个比较适合做一些简单的应用。
总结
在 Exchange 的基础上我们可以通过比较简单的配置绑定关系来灵活的使用消息路由，在简单的应用中也可以直接使用 RabbitMQ 提供的 Default Exchange 而无需关心 Exchange 和绑定关系。Direct Exchange、Topic Exchange、Fanout Exchange 三种类型的交换机的使用方式也很简单，容易掌握。
四、消息确认机制（ACK）
1. 什么是消息确认ACK？
如果在处理消息的过程中，消费者的服务器在处理消息的时候出现异常，那么可能这条正在处理的消息就没有完成消息消费，数据就会丢失。为了确保数据不会丢失，RabbitMQ支持消息确认-ACK
2. 消息确认机制ACK具体是如何实现的
ACK机制是消费者从RabbitMQ收到消息并处理完成后，反馈给RabbitMQ，RabbitMQ收到反馈后才将此消息从队列中删除。
当RabbitMQ收到客户端的获取消息请求之后，RabbitMQ将该消息状态标记为处理中，当收到客户端处理完成后的ack之后，RabbitMQ才会标记为已完成，然后从队列中删除。当RabbitMQ检测到客户端和自己断开链接之后，还没收到ack，则会重新将消息放回消息队列，交给下一个客户端处理（如果有多个消费者的话），保证消息不丢失，也就是说，RabbitMQ给了客户端足够长的时间来做数据处理。
这种机制保证了在消费者服务端故障的时候，不丢失任何消息和任务。
注意：收到ACK前，不会把消息再次发送给该消费者，但是会把下一条消息发送给其他消费者。
3. 消息确认机制ACK的开发注意事项
如果忘记了ACK，那么后果很严重。当Consumer退出时候，Message会一直重新分发。然后RabbitMQ会占用越来越多的内容，由于RabbitMQ会长时间运行，因此这个"内存泄漏"是致命的。
五、Message durability-消息持久化
如果我们希望即使在RabbitMQ服务重启的情况下，也不会丢失消息，我们可以将Queue与Message都设置为可持久化的（durable），这样可以保证绝大部分情况下我们的RabbitMQ消息不会丢失。但依然解决不了小概率丢失事件的发生（比如RabbitMQ服务器已经接收到生产者的消息，但还没来得及持久化该消息时RabbitMQ服务器就断电了），如果我们需要对这种小概率事件也要管理起来，那么我们要用到事务。由于这里仅为RabbitMQ的简单介绍，所以这里将不讲解RabbitMQ相关的事务。
六、Prefetch count
前面我们讲到如果有多个消费者同时订阅同一个Queue中的消息，Queue中的消息会被平摊给多个消费者。这时如果每个消息的处理时间不同，就有可能会导致某些消费者一直在忙，而另外一些消费者很快就处理完手头工作并一直空闲的情况。我们可以通过设置prefetchCount来限制Queue每次发送给每个消费者的消息数，比如我们设置prefetchCount=1，则Queue每次给每个消费者发送一条消息；消费者处理完这条消息后Queue会再给该消费者发送一条消息。
七、RPC
MQ本身是基于异步的消息处理，前面的示例中所有的生产者（P）将消息发送到RabbitMQ后不会知道消费者（C）处理成功或者失败（甚至连有没有消费者来处理这条消息都不知道）。
但实际的应用场景中，我们很可能需要一些同步处理，需要同步等待服务端将我的消息处理完成后再进行下一步处理。这相当于RPC（Remote Procedure Call，远程过程调用）。在RabbitMQ中也支持RPC。
RabbitMQ中实现RPC的机制是：
1）客户端发送请求（消息）时，在消息的属性（MessageProperties，在AMQP协议中定义了14种properties，这些属性会随着消息一起发送）中设置两个值replyTo（一个Queue名称，用于告诉服务器处理完成后将通知我的消息发送到这个Queue中）和correlationId（此次请求的标识号，服务器处理完成后需要将此属性返还，客户端将根据这个id了解哪条请求被成功执行了或执行失败）
说明：
在AMQP规范中，correlation-id是“应用级别”的属性，并没有提供正式的行为定义。这就意味着你可以利用它们实现任何目的，这两个字段允许最多255个字节的UTF-8编码数据，并以未压缩的方式存储在Basic.Properties数据结构中。
reply-to属性被指定用于应用程序，但是没有规定的行为，他还有一个附加说明：使用reply-to可以构架一个用来回复消息的私有响应队列。
2）服务器端收到消息并处理
3）服务器端处理完消息后，将生成一条应答消息到replyTo指定的Queue，同时带上correlationId属性
4）客户端之前已订阅replyTo指定的Queue，从中收到服务器的应答消息后，根据其中的correlationId属性分析哪条请求被执行了，根据执行结果进行后续业务处理。
参考链接：https://www.cnblogs.com/williamjie/p/9481774.html