1.rabbitmq的安装及基本概念

安装

centos

看这个老哥的吧,https://www.cnblogs.com/rmxd/p/11583932.html

mac

1.homebrew安装（mac下最简单的安装方式）

1.安装homebrew
2.安装rabbitmq

 // 更新brew资源
  brew update
  // 执行安装
  brew install rabbitmq

MQ的安装目录在 /usr/local/Cellar/rabbitmq
这样子就表示安装成功了。

image.png

==可视化插件的话,通过这个方式是不用自己安装的。看上图第41行，已经默认帮我们安装了。==

启动：
brew services start rabbitmq

关闭:
stop

重启:
restart

2.docker安装（其他操作系统都可以）

搜索镜像：
docker search rabbitmq

拉取镜像：
docker pull 列表中官方的那个镜像名称

image.png

拉取镜像：docker run -d –name rabbitmq -p 5671:5671 -p 5672:5672 -p 4369:4369 -p 25672:25672 -p 15671:15671 -p 15672:15672 rabbitmq:management

输入web客户端网址:http://IP:15672/ 账号密码：guest/guest

基本概念

连接

首先作为客户端（无论是生产者还是消费者），你如果要与 RabbitMQ 通讯的话，你们之间必须创建一条 TCP 连接，当然同时建立连接后，客户端还必须发送一条“问候语”让彼此知道我们都是符合AMQP的语言的，比如你跟别人打招呼一般会说“你好！”，你跟国外的美女一般会说“hello!”一样。你们确认好“语言”之后，就相当于客户端和 RabbitMQ 通过“认证”了。你们之间可以创建一条 AMQP 的信道。

信道

概念：信道是生产者/消费者与 RabbitMQ 通信的渠道。信道是建立在TCP连接上的虚拟连接，什么意思呢？就是说 rabbitmq在一条TCP上建立成百上千个信道来达到多个线程处理，这个TCP被多个线程共享，每个线程对应一个信道，信道在RabbitMQ都有唯一的ID,保证了信道私有性，对应上唯一的线程使用

疑问：为什么不建立多个 TCP 连接呢？原因是 rabbit 保证性能，系统为每个线程开辟一个TCP是非常消耗性能，每秒成百上千的建立销毁 TCP 会严重消耗系统。所以 rabbitmq 选择建立多个信道（建立在tcp的虚拟连接）连接到 rabbit 上。

从技术上讲，这被称之为“多路复用”，对于执行多个任务的多线程或者异步应用程序来说，它非常有用。

生产者、消费者、消息

生产者 ：消息的创建者，发送到 rabbitmq；

消费者 ：连接到rabbitmq，订阅到队列上，消费消息，持续订阅(basicConsumer)和单条订阅(basicGet).

消息 ：包含有效载荷和标签，有效载荷指要传输的数据，，标签描述了有效载荷，并且rabbitmq用它来决定谁获得消息，消费者只能拿到有效载荷，

交换器、队列、绑定、路由键

队列通过路由键（routingkey，某种确定的规则）绑定到交换器，生产者将消息发布到交换器，交换器根据绑定的路由键将消息路由到特定队列，然后由订阅这个队列的消费者进行接收。

虚拟主机

虚拟消息服务器，vhost，本质上就是一个 mini 版的 mq 服务器，有自己的队列、交换器和绑定，最重要的，自己的权限机制。Vhost提供了逻辑上的分离，可以将众多客户端进行区分，又可以避免队列和交换器的命名冲突。Vhost 必须在连接时指定，rabbitmq包含缺省host：“/”，通过缺省用户和口令 guest 进行访问。

rabbitmq 里创建用户，必须要被指派给至少一个vhost，并且只能访问被指派内的队列、交换器和绑定。Vhost必须通过 rabbitmq 的管理控制工具创
建。

image.png

消息确认

消费者收到的每一条消息都必须进行确认（自动确认和自行确认）。

消费者在声明队列时，可以指定 autoAck 参数，当 autoAck=false 时，RabbitMQ 会等待消费者显式发回 ack 信号后才从内存(和磁盘，如果是持久化消息的话)中移去消息。否则，RabbitMQ会在队列中消息被消费后立即删除它。

采用消息确认机制后，只要令autoAck=false，消费者就有足够的时间处理消息(任务)，不用担心处理消息过程中消费者进程挂掉后消息丢失的问题，因为RabbitMQ会一直持有消息直到消费者显式调用 basicAck 为止。

当 autoAck=false时，对于RabbitMQ服务器端而言，队列中的消息分成了两部分：一部分是等待投递给消费者的消息；一部分是已经投递给消费者，但是还没有收到消费者 ack 信号的消息。如果服务器端一直没有收到消费者的 ack 信号，并且消费此消息的消费者已经断开连接，则服务器端会安排该消息重新进入队列，等待投递给下一个消费者（也可能还是原来的那个消费者）

RabbitMQ 不会为未ack的消息设置超时时间，它判断此消息是否需要重新投递给消费者的唯一依据是消费该消息的消费者连接是否已经断开。这么设计的原因是 RabbitMQ 允许消费者消费一条消息的时间可以很久很久。

下一篇,rabbitmq-交换机详解