RabbitMQ高可用原理

原文：https://www.jksxit.com/essay/47

(一） 功能和原理

设计集群的目的

• 允许消费者和生产者在RabbitMQ节点崩溃的情况下继续运行
• 通过增加更多的节点来扩展消息通信的吞吐量

1 集群配置方式

RabbitMQ可以通过三种方法来部署分布式集群系统，分别是：cluster,federation,shovel

• cluster:
• 不支持跨网段，用于同一个网段内的局域网
• 可以随意的动态增加或者减少
• 节点之间需要运行相同版本的RabbitMQ和Erlang
• federation:应用于广域网，允许单台服务器上的交换机或队列接收发布到另一台服务器上交换机或队列的消息，可以是单独机器或集群。federation队列类似于单向点对点连接，消息会在联盟队列之间转发任意次，直到被消费者接受。通常使用federation来连接internet上的中间服务器，用作订阅分发消息或工作队列。
• shovel:连接方式与federation的连接方式类似，但它工作在更低层次。可以应用于广域网。

2 节点类型

• RAM node:内存节点将所有的队列、交换机、绑定、用户、权限和vhost的元数据定义存储在内存中，好处是可以使得像交换机和队列声明等操作更加的快速。
• Disk node:将元数据存储在磁盘中，单节点系统只允许磁盘类型的节点，防止重启RabbitMQ的时候，丢失系统的配置信息。
  问题说明： RabbitMQ要求在集群中至少有一个磁盘节点，所有其他节点可以是内存节点，当节点加入或者离开集群时，必须要将该变更通知到至少一个磁盘节点。如果集群中唯一的一个磁盘节点崩溃的话，集群仍然可以保持运行，但是无法进行其他操作（增删改查），直到节点恢复。
  解决方案：设置两个磁盘节点，至少有一个是可用的，可以保存元数据的更改。

3 Erlang Cookie

Erlang Cookie是保证不同节点可以相互通信的密钥，要保证集群中的不同节点相互通信必须共享相同的Erlang Cookie。具体的目录存放在/var/lib/rabbitmq/.erlang.cookie。
说明： 这就要从rabbitmqctl命令的工作原理说起，RabbitMQ底层是通过Erlang架构来实现的，所以rabbitmqctl会启动Erlang节点，并基于Erlang节点来使用Erlang系统连接RabbitMQ节点，在连接过程中需要正确的Erlang Cookie和节点名称，Erlang节点通过交换Erlang Cookie以获得认证。

4 镜像队列

功能和原理
RabbitMQ的Cluster集群模式一般分为两种，普通模式和镜像模式。

• 普通模式：默认的集群模式，以两个节点（rabbit01、rabbit02）为例来进行说明。对于Queue来说，消息实体只存在于其中一个节点rabbit01（或者rabbit02），rabbit01和rabbit02两个节点仅有相同的元数据，即队列的结构。当消息进入rabbit01节点的Queue后，consumer从rabbit02节点消费时，RabbitMQ会临时在rabbit01、rabbit02间进行消息传输，把A中的消息实体取出并经过B发送给consumer。所以consumer应尽量连接每一个节点，从中取消息。即对于同一个逻辑队列，要在多个节点建立物理Queue。否则无论consumer连rabbit01或rabbit02，出口总在rabbit01，会产生瓶颈。当rabbit01节点故障后，rabbit02节点无法取到rabbit01节点中还未消费的消息实体。如果做了消息持久化，那么得等rabbit01节点恢复，然后才可被消费；如果没有持久化的话，就会产生消息丢失的现象。
• 镜像模式：将需要消费的队列变为镜像队列，存在于多个节点，这样就可以实现RabbitMQ的HA高可用性。作用就是消息实体会主动在镜像节点之间实现同步，而不是像普通模式那样，在consumer消费数据时临时读取。缺点就是，集群内部的同步通讯会占用大量的网络带宽。
  在上述的集群中，如果某个节点挂掉，整个集群还是可以正常工作的，但是挂掉的那个节点的消息就清空了。这种情况在生产环境中是不可接受的，所以需要用到镜像功能，也就是主从配置。
  在集群中的任意一台主机上执行：
  rabbitmqctl set_policy ha-all “^” ‘{“ha-mode”:”all”}’
  意思表示所有queue都会复制到各个节点 [“^”匹配所有]