RabbitMQ浅入

启动rabbitmq-server

启动rabbitmq服务，以便使用

systemctl start rabbitmq-server

查看服务状态

rabbitmqctl status

如果能显示一大堆版本信息等等的，那么就意味着启动成功了

访问可视化界面

http://127.0.0.1:15672

如果可以访问的话将会显示以下界面



如果不能访问则需要开启rabbitmq管理后台插件，用下面的命令开启

rabbitmq-plugins enable rabbitmq_management

等待插件开启完成后，再访问本地的http://127.0.0.1:15672，就能成功显示rabbitmq管理后台的可视化界面，rabbitmq提供了默认的账号和密码，用默认账号和密码就能登录成功，将会展示节点的一些信息和服务状态

账号：guest
密码：guest

rabbitmq插件管理

查看插件状态

rabbitmq-plugins list			

在[]中如果是空的表明该插件没有启动，如果是e*就是说该插件已经启动了

停止rabbitmq服务

rabbitmqctl stop

概念介绍

在管理后台界面中有些需要了解的知识

• Virtual Host

用于逻辑隔离，比如说在开发环境和测试环境中，用的都是同样一台的rabbitmq服务，生成的都是同样的数据，但是要有区分，那就所需要逻辑隔离，将两者区别

• Connection

展示监听进程的连接

• Exchange

交换机，相当于中转，一个生产者发送消息，会先进入exchange里面，根据指定的规则绑定对应的key，把所有的消息存储到对应的key中

• Channel

在连接中通过channel进行通讯

• Queue

绑定交换机或接收消息，等待消费者从队列中取出消息，承担着临时存储消息的作用

• Binding

通过不同方式的绑定可以实现rabbitmq不同工作模式

消息模型

• 生产者（producer)：发布消息的应用程序
• 队列（queue）：用于消息存储的缓冲
• 消费者（consumer）：接收消息的应用程序

RabbitMQ 消息模型的核心理念是：发布者（producer）不会直接发送任何消息给队列。事实上，发布者（producer）甚至不知道消息是否已经被投递到队列。

生产者（producer）只需把消息发送给一个交换机（exchange）。交换机非常简单，它一边从发布者接收消息，一边把消息消息推送到队列。交换机必须知道如何处理它接收的消息，是应该推送到指定的队列还是多个队列，或者是直接忽略消息。这些规则是通过交换机类型（exchange type）来定义的。

交换机类型：direct（直连），topic（主题），headers（头部）、fanout（广播）。

交换机和队列之间的联系我们称之为绑定（ binding ），即交换机如何发送消息给我们的队列。

工作模式

整体使用

RabbitMQ 使用的是 AMQP 协议。要使用 rabbitmq，你需要一个库来解读这个协议。几乎所有的编程语言都有可选择的库，可以自行查找解决方案解决。

• Simple模式

生产者（Producer）把消息发送到一个队列中。消费者（Consumer）从这个队列中获取消息。

• Work模式

一个消息只能被一个消费者获取，好处就是它能够并行的处理队列。如果堆积了很多任务，我们只需要添加更多的工作者（workers）就可以了，扩展很简单。默认来说，RabbitMQ 会按顺序得把消息发送给每个消费者（consumer），平均每个消费者都会收到同等数量得消息。这种发送消息得方式叫做——轮询（round-robin），当然也可以采用其他策略来保证均衡。

• Publish/Subscribe模式

指定交换机类型，分发一个消息给多个消费者，需要为交换机和队列之间建立联系，即交换机通过什么规则发送消息给我们的队列。

• Routing模式

通过绑定的关系，路由的算法——交换机将会对绑定键（ binding key ）和路由键（routing key ）进行精确匹配，从而确定消息该分发到哪个队列。

绑定的时候可以带上一个额外的 routing_key 参数，我们把它叫做绑定键（ binding key ）。绑定键的意义取决于交换机的类型。比如我们之前使用过的广播交换机（ fanout exchanges ）会忽略这个值。

在这个场景中，我们可以看到直连（ direct ）交换机 X 和两个消息队列进行了绑定。C1使用 error 作为绑定键，C2队列有三个绑定键（info、error、warning）

这样以来，当路由键为 error 的消息发布到交换机，就会被路由到 C1 。路由键为 info、error、warning 的消息就会路由到 C2。其他的所有消息都将会被丢弃。

• Topic模式

发送到主题交换机（topic exchange）的消息不可以携带随意格式的路由键（routing_key），它的路由键必须是一个由 .分隔开的词语列表。

绑定键也必须拥有同样的格式，一个携带着特定路由键的消息会被主题交换机投递给绑定键与之相匹配的队列。但是它的绑定键和路由键有两个特殊应用方式：

• *用来表示一个单词

• #用来表示任意数量（零个或多个）单词
  
  
  

• RPC模式

远程过程调用，需要构建一个客户端和一个可扩展的RPC服务端，对于一个RPC request，客户端发送message时设置两个属性：replyTo设置成仅为请求创建的匿名独占队列以及为每个request设置一个唯一的correlationld。请求被发送到rpc_queue队列，RPC worker监听rpc_queue，当有消息时，进行计算并通过replyTo指定的queue发送带有执行结果的消息给客户端。客户端监听回调queue，当接收到message，则检查correlationld，如果和之前的request的correlationld匹配，则将消息返回给应用进行处理，如果不匹配，则忽略。

你也许会问，为什么我们接收到未知消息的时候不抛出一个错误，而是要将它忽略掉？这是为了解决服务器端有可能发生的竞争情况。尽管可能性不大，但 RPC 服务器还是有可能在已将应答发送给我们但还未将确认消息发送给请求的情况下死掉。如果这种情况发生，RPC 在重启后会重新处理请求。这就是为什么我们必须在客户端优雅的处理重复响应，同时 RPC 也需要尽可能保持 幂等性。

AMQP 协议给消息预定义了一系列的 14 个属性。

• content_type（内容类型）:用来描述编码的 mime-type。例如在实际使用中常常使用 application/json 来描述 JOSN 编码类型。

• reply_to（回复目标）：通常用来命名回调队列。

• correlation_id（关联标识）：用来将 RPC 的响应和请求关联起来。

消息机制

①ack（acknowledgments）：消息响应

当处理一个比较耗时得任务的时候，你也许想知道消费者（consumers）是否运行到一半就挂掉。当前的代码中，当消息被 RabbitMQ 发送给消费者（consumers）之后，马上就会在内存中移除。这种情况，你只要把一个工作者（worker）停止，正在处理的消息就会丢失。同时，所有发送到这个工作者的还没有处理的消息都会丢失。

我们不想丢失任何任务消息。如果一个工作者（worker）挂掉了，我们希望任务会重新发送给其他的工作者（worker）。

为了防止消息丢失，RabbitMQ 提供了消息响应（acknowledgments）。消费者会通过一个 ack（响应），告诉 RabbitMQ 已经收到并处理了某条消息，然后 RabbitMQ 就会释放并删除这条消息。

如果消费者（consumer）挂掉了，没有发送响应，RabbitMQ 就会认为消息没有被完全处理，然后重新发送给其他消费者（consumer）。这样，及时工作者（workers）偶尔的挂掉，也不会丢失消息。

消息是没有超时这个概念的；当工作者与它断开连的时候，RabbitMQ 会重新发送消息。这样在处理一个耗时非常长的消息任务的时候就不会出问题了。

②durable：持久化

如果你没有特意告诉 RabbitMQ，那么在它退出或者崩溃的时候，将会丢失所有队列和消息。为了确保信息不会丢失，有两个事情是需要注意的：我们必须把 “队列” 和 “消息” 设为持久化。

注意：将消息设为持久化并不能完全保证不会丢失。以上代码只是告诉了 RabbitMq 要把消息存到硬盘，但从 RabbitMq 收到消息到保存之间还是有一个很小的间隔时间。它有可能只是保存到缓存中，并不一定会写到硬盘中。并不能保证真正的持久化，但已经足够应付我们的简单工作队列。

相关代码

代码实现

参考

https://www.shiyanlou.com/courses/630