RabbitMQ

• 持久化

  • 持久化必要条件（缺一不可）

    • 把投递模式选项设置为2（持久）

    • 发送到持久化的交换器

    • 到达持久化的队列

  • 如何知道服务器已经将消息持久化到硬盘？

    • AMQP事务

      • 概述

        • 在AMQP中把信道设置成事务模式后，通过信道发送那些想要确认的消息，之后还有多个其他AMQP命令，这些命令是执行还是忽略取决于第一条消息是否发送成功，一旦发送所有命令，就可以提交事务。

      • 缺点

        • 性能低下，会降低大约2-10倍的消息吞吐量，而且会使生产者应用程序产生同步

    • 发送方确认模式

      • 需要将信道设置成confirm模式channel.confirmSelect();

      • 一旦消息被投递给所有匹配队列后，信道会发送一个发送方确认模式给生产者应用程序，如果消息和队列是可持久化的，那么会在写入磁盘后发出。

      • 发送方确认模式是异步的

• 信道

  • 概念

    • 建立在TCP连接内的虚拟连接，AMQP命令都是通过信道发送的。

  • 特点

    • 无需频繁建立和销毁TCP连接，提高了性能

    • 不论发布消息、订阅队列或是接收消息，这些动作都是通过信道完成的

    • 在一个TCP连接上创建的信道数量是没有限制的

• ​AMQP

  • 概念

    • Advanced Message Queuing Protocol 高级消息队列协议

  • 消息路由

    1. 生产者把消息发布到交换器上；
    2. 教习最终到达队列，并被消费者接收；
    3. 绑定决定了消息如何从路由器路由到特定的队列。

    • 组成部分

      • 交换器

        • direct

          • 路由键完全匹配，消息就会投递到对应队列

        • fanout

          • 忽略路由键匹配，将消息投递到所有绑定的队列上

        • topic

          • 通过 . 分隔路由键匹配，如 *.msg-inbox ，可以匹配如 err.msg-inbox, info.msg-inbox 等消息的路由键，也可使用 # 匹配所有路由键

        • headers

          • headers交换器允许你匹配AMQP消息的header而非路由键，除此之外headers和direct完全一致，但性能会差很多，因此并不实用。

      • 绑定

        • 路由键

          • 概念

            • 决定RabbitMQ将消息投递到哪个队列的规则

          • 作用

            • 队列通过路由键绑定到交换器

      • 队列

        • 常用参数

          • exclusive

            • 设置为true时变为私有，即只有一个消费者

          • autoDelete

            • 当最后一个消费者取消订阅的时候，队列就会自动移除

          • ​durable

            • ​是否持久化

          • ​arguments

            • ​其他参数

        • 谁来创建

          • 如果不能承担消息丢失，则消费者和生产者都应该尝试创建队列，如果可以承担丢失消息，则只需让消费者创建队列。

        • 负载均衡

          • 对负载均衡来说，队列是绝佳方案，只需附加一堆消费者，并让RabbitMQ以循环的方式均匀地分配发来的消息即可

    • 消息确认

      • 消费者接收到的每一条消息都必须确认，可以显式确认（Channel接口中的basicAck方法），或者在设置autoAck为true。

      • 消费者对消息的确认和告诉生产者消息已经被接收了这两件事毫不相关

      • 当消费者确认接收到消息之后，RabbitMQ才能安全地把消息从队列中删除

      • 不确认消息的情况

        • 确认前从Rabbit断开连接

          • RabbitMQ会重新分发给下一个订阅的消费者

        • 因bug或其他原因忘记确认

          • RabbitMQ不会给这个消费者发送更多消息，因为在上一条消息被确认之前，Rabbit会认为这个消费者并没有准备好接收下一条消息

        • 主动拒绝确认

          • 设置basicNack或basicReject方法中的queue参数，如果为true，则Rabbit会把消息重新发送给下一个订阅的消费者，如果为false，Rabbit会把消息移除而不会发送给新的消费者

• vhost

  • 概念

    • 每一个RabbitMQ服务器都能创建虚拟消息服务器，称之为虚拟主机（vhost）。每一个vhost本质上是一个mini版本的RabbitMQ服务器，拥有自己的队列、交换器和绑定甚至自己的权限机制。默认的vhost： "/"，用户名密码均为guest

  • 隔离性

    • vhost之间完全隔离

  • 创建vhost

    • 只能使用rabbitmqctl命令工具创建
      rabbitmqctl add_vhost [vhost name]

• 集群

  • 概览

    • 特点

      • RabbitMQ默认不会将队列的内容复制到整个集群上，如果不进行特别配置，这些消息仅存在于队列所属的那个节点上

      • 所有其他非所有者节点只知道队列的元数据和指向该队列存在的哪个节点的指针

    • 原因

      • 存储空间

        • 如果每个集群节点都拥有所有队列的完整拷贝，那么添加新的节点不会带来更多存储空间

      • 性能

        • 如果将消息复制到每个集群节点，则对于持久化消息来说，每一条都会触发磁盘活动，降低性能

    • 总结

      • 通过设置集群中的唯一节点来负责任何特定队列，只有该负责节点才会因队列消息而遭受磁盘活动的影响。所有其他节点需要将接收到的该队列的消息传递给该队列的所有者节点。因此添加更多节点意味着拥有更多的节点来传播队列。

  • 集群架构

    • 内部元数据

      • 队列元数据

        • 队列名称和它们的属性（是否可持久化，是否自动删除）

      • 交换器元数据

        • 交换器名称、类型和属性（可持久化等）

      • 绑定元数据

        • 一张简单的表格展示了如何将消息路由到队列

      • vhost元数据

        • 为vhost内的队列、交换器和绑定提供命名空间和安全属性

    • 单一节点内，RabbitMQ会将所有元数据信息存储再内存中，同时将标记为可持久化的队列和交换器以及绑定存储到硬盘上

  • 分布交换器

    • ​交换器说到底只是一个名称和一个队列绑定列表，正是信道（channel）按照绑定匹配的结果，将消息路由到队列

    • ​由于交换器只不过是一张查询表，而不是实际上的消息路由器，因此将交换器在整个集群中进行复制会更加简单

    • ​优点：集群中的每个节点拥有每个交换器的所有信息意味着不用担心在节点故障时重新声名交换器，只需要让故障节点上的生产者重新连接到集群上，它们就能立即开始往交换器上发布消息。

  • ​内存节点还是磁盘节点

    • ​集群中至少需要一个磁盘节点，所有其他节点都可以是内存节点

    • ​当节点加入或者离开集群时，必须要将该变更通知到至少一个磁盘节点

    • ​如果掉线的是仅有的一个磁盘节点，集群依然可以继续路由消息，但是不能做以下操作
      - 创建队列
      - 创建交换器
      - 创建绑定
      - 添加用户
      - 更改权限
      - 添加或删除集群节点（需要所有磁盘节点都在线才能做的操作）
      

      • ​解决方案

        • ​设置至少两个磁盘节点

  • ​创建集群

    • ​停止当前节点 rabbitmqctl stop_app
      

    • ​重置节点元数据和状态 rabbitmqctl reset

    • ​加入到集群节点 rabbitmqctl join_cluster [name]@[hostname]
      使用 --ram 参数变成磁盘节点

    • ​启动节点 rabbitmqctl start_app

  • ​镜像队列

    • ​说明

      • ​镜像队列的主拷贝仅存在于一个节点（主队列，master）上
        其他节点上拥有从队列（slave）拷贝
        一旦队列主节点不可用，最老的从队列将被选举为新的主队列

    • ​管理

      • ​创建

        • ​在channel的queueDeclare方法中声名最后一个map类型的参数
          {"x-ha-policy":"all"}
          all表示让队列镜像到所有集群的节点上，如果声名之后又增加节点，则新增加的节点会自动托管一份队列的从拷贝

        • ​将镜像队列镜像到指定节点上
          {
            "x-ha-policy" : "nodes",
            "x-ha-policy-params" : [
              "rabbit1@host1",
              "rabbit2@host2"
            ]
          }

      • ​查看

        • ​rabbitmqctl list_queues name pid slave_pids

      • ​注意事项

        • ​为了使队列镜像到指定节点中，必须在程序中硬编码，如果任何一个节点发生故障或者从集群中移除，那么该声名就会失败，同时也不利于后续扩展，所以尽可能采用all来设置x-ha-policy

        • ​虽然是叫从队列（从拷贝），但是从队列的消息是从交换器（信道）直接发送过来的，并不是从主队列复制过来的，所以可以想象成镜像队列拥有一个隐藏的fanout交换器

        • ​由于从队列的消息是从交换器直接投递的，所以新增的从队列并不会拥有还未消费的旧消息

        • ​使用发送方确认模式时，只有在所有主从拷贝队列安全地接收到消息时才会收到确认通知

    • ​故障

      • ​主拷贝的节点故障

        • ​所有消费者需要重新附加并监听新的队列主拷贝

          • ​主拷贝消费者

            • ​会自动选取新的队列主拷贝

          • ​从拷贝消费者

            • ​RabbitMQ会发送给这些消费者一个消费者取消通知（consumer cancellation），此时程序会抛出异常，应用程序就会知道已经不再附加到队列上了，需要重新附加

            • ​如果使用的AMQP客户端库不支持消费者取消通知，客户端就无法知道队列的主拷贝已不存在，程序会以为队列里没有消息可用，然而此时消息却被积压在其他从拷贝队列中，因此在不支持消费者取消通知的AMQP客户端应该避免使用镜像队列。

        • ​已经消费但尚未确认的消息会重新入队到原来队列的位置

      • ​从拷贝的节点故障

        • ​所有消费者都不会感知到，不会影响正常工作