在部署安装rabbitmq后除了应用程序外，开发人员主要使用的就是控制台。
    image.png

    在这里我们可以得到rabbitmq服务的所有内容，控制台大体分为了六个部分：
    1）overview-概览信息展示，主要查看服务节点和统计信息。
    image.png
    2）connections-连接节点，主要展示连接并使用MQ服务的应用节点，注意如果我们的应用启动后没有使用它，那么这里是没有内容的。我启动了一个生产者并随便推送了个消息，然后列表展示如下：
    image.png
    3）channels-通道，和连接节点长相类似，他是基于“连接”基础上的线程级显示，一个“连接”可以创建多个通道，使用多线程的方式，一个应用或一个线程都是一个通道。
    image.png
    4）exchanges-交换机，用来接收生产者的消息，并将这些消息路由到MQ服务的指定队列中。
    image.png
    交换机名称对应的类型解释如下：

    Type 解释
    direct 它会把消息路由到那些 binding key 与 routing key 完全匹配的 Queue 中
    fanout 它会把所有发送到该 Exchange 的消息路由到所有与它绑定的 Queue 中
    headers headers 类型的 Exchange 不依赖于 routing key 与 binding key 的匹配规则来路由消息，而是根据发送的消息内容中的 headers 属性进行匹配。（headers 类型的交换器性能差，不实用，基本不会使用。）
    topic 与direct模型相比，多了个可以使用通配符！，这种模型Routingkey一般都是由一个或多个单词组成，多个单词之间以”.”分割，例如：item.insert ————-星号 匹配一个1词 , 例audit.* ———- #号匹配一个或多个词 audit.#
    x-delayed-message 延迟交换机，可以延迟接收消息

    根据不同的场景我们在设置生产者发布消息到交换机时，允许消费者以各类方式来获取到消息数据。
    5）queues-队列，这里存储的就是生产者实际推送消息，消费者通过监听进行消息消费。
    image.png
    MQ服务相对不好理解的点就在于，很多东西需要事先添加，或者程序内要做自动声明，否则单单在控制台上也看不到详细东西。
    比如说我们只启动了一个生产者，然后定时向指定的queue推送消息，如果未先创建queue那么在控制台是无法看到推送的消息。
    当然了，这也并不影响我们的使用，毕竟正常逻辑下没有谁去只生产消息，或者消费一个光头司令。
    6）admin-用户，相当于rabbitmq的用户管理，配置访问和使用用户的，毕竟专人干专事儿，不能啥都用guest用户，就像是服务器上不能只会用root～