RabbitMQ理解与应用

1、为什么要使用消息队列

主要总结为以下六个字：解耦、异步、削峰

1.1 应用解耦

场景：双11是购物狂节,用户下单后,订单系统需要通知库存系统,传统的做法就是订单系统调用库存系统的接口。
缺点：库存系统与订单系统高度耦合 ，当库存系统出现故障时,订单就会失败。
优化:
订单系统:用户下单后,订单系统完成持久化处理,将消息写入消息队列,返回用户订单下单成功。
库存系统:订阅下单的消息,获取下单消息,进行库操作。
即使库存系统出现故障,消息队列也能保证消息的可靠投递,不会导致消息丢失。

1.2 异步处理

场景：用户注册后，需要发注册邮件和注册短信,传统的做法是串行的方式
串行方式:将注册信息写入数据库后,发送注册邮件,再发送注册短信,以上三个任务全部完成后才返回给客户端。 这有一个问题是,邮件,短信并不是必须的,它只是一个通知,而这种做法让客户端等待没有必要等待的东西。
假设三个业务节点分别使用50ms,串行方式使用时间150ms,邮件和短信对我正常的使用网站没有任何影响，客户端没有必要等着其发送完成才显示注册成功,应该是写入数据库后就返回。
引入消息队列后，把发送邮件,短信不是必须的业务逻辑异步处理
由此可以看出,引入消息队列后，用户的响应时间就等于写入数据库的时间+写入消息队列的时间(可以忽略不计),引入消息队列后处理后,响应时间是串行的3倍。

1.3 流量削峰

场景:秒杀活动，一般会因为流量过大，导致应用挂掉,为了解决这个问题，一般在应用层加入消息队列。
作用:
1.可以控制活动人数，超过此一定阀值的订单直接丢弃
用户的请求,服务器收到之后,首先写入消息队列,加入消息队列长度超过最大值,则直接抛弃用户请求或跳转到错误页面.
2.可以缓解短时间的高流量压垮应用

2、ActiveMq、RabbitMQ、Kafka的比较

3、RabbitMQ介绍

RabbitMQ 是实现 AMQP（高级消息队列协议）的消息中间件的一种，最初起源于金融系统，用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。 RabbitMQ 主要是为了实现系统之间的双向解耦而实现的。当生产者大量产生数据时，消费者无法快速消费，那么需要一个中间层。保存这个数据。
AMQP，即 Advanced Message Queuing Protocol，高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。消息中间件主要用于组件之间的解耦，消息的发送者无需知道消息使用者的存在，反之亦然。AMQP 的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全。
RabbitMQ 是一个开源的 AMQP 实现，服务器端用Erlang语言编写，支持多种客户端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP 等，支持 AJAX。用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。
消息队列运转过程图：

3.1 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、关闭连接。
如图2-9 所示，我们又引入了两个新的概念: Connection 和Channel 。我们知道无论是生产者还是消费者，都需要和RabbitMQ Broker 建立连接，这个连接就是一条TCP 连接，也就是Connection 。一旦TCP 连接建立起来，客户端紧接着可以创建一个AMQP 信道(Channel) ，每个信道都会被指派一个唯一的 。信道是建立在Connection 之上的虚拟连接， RabbitMQ 处理的每条AMQP 指令都是通过信道完成的。

我们完全可以直接使用Connection 就能完成信道的工作，为什么还要引入信道呢?试想这样一个场景， 一个应用程序中有很多个线程需要从RabbitMQ 中消费消息，或者生产消息，那么必然需要建立很多个Connection ，也就是许多个TCP 连接。然而对于操作系统而言，建立和销毁TCP 连接是非常昂贵的开销，如果遇到使用高峰，性能瓶颈也随之显现。RabbitMQ 采用类似NIO’ (Non-blocking 1/0) 的做法，选择TCP 连接复用，不仅可以减少性能开销，同时也便于管理。
NIO: 也称非阻塞IO ， 包含三大核心部分Channel (信道)、Buffer (缓冲区)和Selector (选择器). NIO 基于Channel 和Buffer 进行操作，数据总是从信道读取数据到缓冲区中，或者从缓冲区写入到信道中。Selector 用于监听多个信道的事件(比如连接打开，数据到达等)。因此，单线程可以监听多个数据的信道。NIO 中有一个很有名的Reactor 模式，有兴趣的读者可以深入研究。
每个线程把持一个信道，所以信道复用了Connection 的TCP 连接。同时RabbitMQ 可以确保每个线程的私密性，就像拥有独立的连接一样。当每个信道的流量不是很大时，复用单一的Connection 可以在产生性能瓶颈的情况下有效地节省TCP 连接资源。但是当信道本身的流量很大时，这时候多个信道复用一个Connection 就会产生性能瓶颈，进而使整体的流量被限制了。此时就需要开辟多个Connection ，将这些信道均摊到这些Connection 中， 至于这些相关的调优策略需要根据业务自身的实际情况进行调节。
信道在AMQP 中是一个很重要的概念，大多数操作都是在信道这个层面展开的。

3、RabbitMQ相关概念

通常的消息队列会有三个核心概念：消息生产者、消息消费者、消息队列。RabbitMQ在原有的生产者与队列之间增加了交换机（Exchange）概念。在实际应用中我们只需要定义好 Exchange 的路由策略，而生产者则不需要关心消息会发送到哪个 Queue 或被哪些 Consumer 消费。在这种模式下生产者只面向 Exchange 发布消息，消费者只面向 Queue 消费消息，Exchange 定义了消息路由到 Queue 的规则，将各个层面的消息传递隔离开，使每一层只需要关心自己面向的下一层，降低了整体的耦合度。大致关系如下图所示：

其中比较重要的概念有 4 个，分别为：虚拟主机，交换机，队列，和绑定。
虚拟主机：一个虚拟主机持有一组交换机、队列和绑定。为什么需要多个虚拟主机呢？很简单，RabbitMQ 当中，用户只能在虚拟主机的粒度进行权限控制。因此，如果需要禁止A组访问B组的交换机/队列/绑定，必须为A和B分别创建一个虚拟主机。每一个 RabbitMQ 服务器都有一个默认的虚拟主机“/”。
交换机：Exchange 用于转发消息，但是它不会做存储，如果没有 Queue bind 到 Exchange 的话，它会直接丢弃掉 Producer 发送过来的消息。这里有一个比较重要的概念：路由键。消息到交换机的时候，交互机会转发到对应的队列中，那么究竟转发到哪个队列，就要根据该路由键。
绑定：也就是交换机需要和队列相绑定，这其中如上图所示，是多对多的关系。

4、交换机(Exchange)

Exchange 收到消息时，他是如何知道需要发送至哪些 Queue呢？这里就需要了解 Binding和RoutingKey的概念：
Binding表示 Exchange 与 Queue 之间的关系，我们也可以简单的认为队列对该交换机上的消息感兴趣，绑定可以附带一个额外的参数 RoutingKey。Exchange 就是根据这个 RoutingKey 和当前 Exchange 所有绑定的 Binding 做匹配，如果满足匹配，就往 Exchange 所绑定的 Queue 发送消息，这样就解决了我们向 RabbitMQ 发送一次消息，可以分发到不同的 Queue。RoutingKey 的意义依赖于交换机的类型。
下面就来了解一下 Exchange 的四种主要类型：Fanout、Direct、Topic、Headers。

4.1 Direct Exchange

Direct Exchange 是 RabbitMQ 默认的 Exchange，完全根据 RoutingKey 来路由消息。设置 Exchange 和 Queue 的 Binding 时需指定 RoutingKey（一般为 Queue Name），发消息时也指定一样的 RoutingKey，消息就会被路由到对应的Queue。效果图如下图所示：

应用场景：
现在我们考虑只把重要的日志消息写入磁盘文件，例如只把 Error 级别的日志发送给负责记录写入磁盘文件的 Queue。这种场景下我们可以使用指定的 RoutingKey（例如 error）将写入磁盘文件的 Queue 绑定到 Direct Exchange 上。

4.2 Topic Exchange

Topic Exchange 和 Direct Exchange 类似，也需要通过 RoutingKey 来路由消息，区别在于Direct Exchange 对 RoutingKey 是精确匹配，而 Topic Exchange 支持模糊匹配。分别支持*和#通配符，*表示匹配一个单词，#则表示匹配没有或者多个单词。

应用场景：
假设我们的消息路由规则除了需要根据日志级别来分发之外还需要根据消息来源分发，可以将 RoutingKey 定义为 消息来源.级别 如 order.info、user.error等。处理所有来源为 user 的 Queue 就可以通过 user.* 绑定到 Topic Exchange 上，而处理所有日志级别为 info 的 Queue 可以通过 *.info 绑定到 Exchange上。

4.3 Fanout Exchange

Fanout Exchange 消息广播的模式，不管路由键或者是路由模式，会把消息发给绑定给它的全部队列，如果配置了 routing_key 会被忽略。效果图如下图所示：

应用场景：
以日志系统为例：假设我们定义了一个 Exchange 来接收日志消息，同时定义了两个 Queue 来存储消息：一个记录将被打印到控制台的日志消息；另一个记录将被写入磁盘文件的日志消息。我们希望 Exchange 接收到的每一条消息都会同时被转发到两个 Queue，这种场景下就可以使用 Fanout Exchange 来广播消息到所有绑定的 Queue。

4.4 Headers Exchange

Headers Exchange 会忽略 RoutingKey 而根据消息中的 Headers 和创建绑定关系时指定的 Arguments 来匹配决定路由到哪些 Queue。
Headers Exchange 的性能比较差，而且 Direct Exchange 完全可以代替它，所以不建议使用。

4.5. Default Exchange

Default Exchange 是一种特殊的 Direct Exchange。当你手动创建一个队列时，后台会自动将这个队列绑定到一个名称为空的 Direct Exchange 上，绑定 RoutingKey 与队列名称相同。有了这个默认的交换机和绑定，使我们只关心队列这一层即可，这个比较适合做一些简单的应用。

5、消息持久化

在生产环境中，我们需要考虑万一生产者挂了，消费者挂了，或者 rabbitmq 挂了怎么样。一般来说，如果生产者挂了或者消费者挂了，其实是没有影响，因为消息就在队列里面。那么万一 rabbitmq 挂了，之前在队列里面的消息怎么办，其实可以做消息持久化，RabbitMQ 会把信息保存在磁盘上。
做法是可以先从 Connection 对象中拿到一个 Channel 信道对象，然后再可以通过该对象设置 消息持久化。
生产者或者消费者断线重连 这里 Spring 有自动重连机制。

6、ACK 确认机制

每个Consumer可能需要一段时间才能处理完收到的数据。如果在这个过程中，Consumer出错了，异常退出了，而数据还没有处理完成，那么 非常不幸，这段数据就丢失了。因为我们采用no-ack的方式进行确认，也就是说，每次Consumer接到数据后，而不管是否处理完 成，RabbitMQ Server会立即把这个Message标记为完成，然后从queue中删除了。
如果一个Consumer异常退出了，它处理的数据能够被另外的Consumer处理，这样数据在这种情况下就不会丢失了（注意是这种情况下）。 为了保证数据不被丢失，RabbitMQ支持消息确认机制，即acknowledgments。为了保证数据能被正确处理而不仅仅是被Consumer收到，那么我们不能采用no-ack。而应该是在处理完数据后发送ack。
在处理数据后发送的ack，就是告诉RabbitMQ数据已经被接收，处理完成，RabbitMQ可以去安全的删除它了。 如果Consumer退出了但是没有发送ack，那么RabbitMQ就会把这个Message发送到下一个Consumer。这样就保证了在Consumer异常退出的情况下数据也不会丢失。
如果对 ACK 机制有疑问点击这里: https://www.zhihu.com/question/41976893

7、安装RabbitMQ

7.1 Windows安装教程

链接：https://www.cnblogs.com/ericli-ericli/p/5902270.html

7.2 Linux安装教程

1、 准备：

yum install 
build-essential openssl openssl-devel unixODBC unixODBC-devel 
make gcc gcc-c++ kernel-devel m4 ncurses-devel tk tc xz

2、 下载：

wget www.rabbitmq.com/releases/erlang/erlang-18.3-1.el7.centos.x86_64.rpm
wget http://repo.iotti.biz/CentOS/7/x86_64/socat-1.7.3.2-5.el7.lux.x86_64.rpm
wget www.rabbitmq.com/releases/rabbitmq-server/v3.6.5/rabbitmq-server-3.6.5-1.noarch.rpm

3、安装 (注意安装顺序)

./socat-1.7.3.2-5.el7.lux.x86_64.rpm
./erlang-18.3-1.el7.centos.x86_64.rpm
./rabbitmq-server-3.6.5-1.noarch.rpm

4、配置文件：

vim /usr/lib/rabbitmq/lib/rabbitmq_server-3.6.5/ebin/rabbit.app

比如修改密码、配置等等，例如：loopback_users 中的 <<“guest”>>,只保留guest (外网IP登录guest账户方法)
5、服务启动和停止：

启动 rabbitmq-server start &
停止 rabbitmqctl stop

6、管理插件：

rabbitmq-plugins enable rabbitmq_management  #启动web管理界面

7、访问地址：http://IP:15672/
8、用户创建、授权

	增加访问用户，默认用户guest只能本地访问。
	rabbitmqctl add_user admin 123456
	设置角色：
	rabbitmqctl set_user_tags admin administrator 
	设置默认vhost（“/”）访问权限
	rabbitmqctl set_permissions -p “/” admin “.” “.” “.*”

8、SpringBoot集成RabbitMQ

代码链接：https://github.com/lxwjq/SpringBoot-RabbitMQ