怎么看rabbitmq的浏览器信息_没用过消息队列？一文带你体验RabbitMQ收发消息

人生终将是场单人旅途，孤独之前是迷茫，孤独过后是成长。

楔子

先给大家说声抱歉，最近都没有发文，有一些比较要紧重要的事需要处理。

今天正好得空，本来说准备写SpringIOC相关的东西，但是发现想要梳理一遍还是需要很多时间，所以我打算慢慢写，先把MQ给写了，再慢慢写其他相关的，毕竟偏理论的东西一遍要比较难写，像MQ这种偏实战的大家可以clone代码去玩一玩，还是比较方便的。

同时MQ也是Java进阶不必可少的技术栈之一，所以Java开发从业者对它是必须要了解的。

现在市面上有三种消息队列比较火分别是：RabbitMQ，RocketMQ和Kafka。

今天要讲的消息队列中我会以RabbitMQ作为案例来入门，因为SpringBoot的amqp中默认只集成了RabbitMQ，用它来讲会方便许多，且RabbitMQ的性能和稳定性都很不错，是一款经过时间考验的开源组件。

祝有好收获。

1. 消息队列？

消息队列（MQ）全称为Message Queue，是一种应用程序对应用程序的通信方法。

翻译一下就是：在应用之间放一个消息组件，然后应用双方通过这个消息组件进行通信。

好端端的为啥要在中间放个组件呢？

小系统其实是用不到消息队列的，一般分布式系统才会引入消息队列，因为分布式系统需要抗住高并发，需要多系统解耦，更需要对用户比较友好的响应速度，而消息队列的特性可以天然解耦，方便异步更能起到一个顶住高并发的削峰作用，完美解决上面的三个问题。

---

然万物抱阳负阴，系统之间突然加了个中间件，提高系统复杂度的同时也增加了很多问题：

• 消息丢失怎么办？
• 消息重复消费怎么办？
• 某些任务需要消息的顺序消息，顺序消费怎么保证？
• 消息队列组件的可用性如何保证？

这些都是使用消息队列过程中需要思考需要考虑的地方，消息队列能给你带来很大的便利，也能给你带来一些对应的麻烦。

上面说了消息队列带来的好处以及问题，而这些不在我们今天这篇的讨论范围之内，我打算之后再写这些，我们今天要做的是搭建出一个消息队列环境，让大家感受一下基础的发消息与消费消息，更高级的问题会放在以后讨论。

2. RabbitMQ一览

RabbitMQ是一个消息组件，是一个erlang开发的AMQP（Advanced Message Queue）的开源实现。

AMQP，即Advanced Message Queuing Protocol,一个提供统一消息服务的应用层标准高级消息队列协议,是应用层协议的一个开放标准,为面向消息的中间件设计。

RabbitMQ采用了AMQP协议，至于这协议怎么怎么样，我们关心的是RabbitMQ结构如何且怎么用。

还是那句话，学东西需要先观其大貌，我们要用RabbitMQ首先要知道它整体是怎么样，这样才有利于我们接下来的学习。

我们先来看看我刚画的架构图，因为RabbitMQ实现了AMQP协议，所以这些概念也是AMQP中共有的。

• Broker: 中间件本身。接收和分发消息的应用，这里指的就是RabbitMQ Server。
• Virtual host: 虚拟主机。出于多租户和安全因素设计的，把AMQP的基本组件划分到一个虚拟的分组中，类似于网络中的namespace概念。当多个不同的用户使用同一个RabbitMQ server提供的服务时，可以划分出多个vhost，每个用户在自己的vhost创建exchange／queue等。
• Connection: 连接。publisher／consumer和broker之间的TCP连接。断开连接的操作只会在client端进行，Broker不会断开连接，除非出现网络故障或broker服务出现问题。
• Channel: 渠道。如果每一次访问RabbitMQ都建立一个Connection，在消息量大的时候建立T