rabbitmq 高可用

RabbitMQ 的高可用性

RabbitMQ 有三种模式：单机模式、普通集群模式、镜像集群模式

1、单机模式不存在高可用。生产环境不使用

2、普通集群模式

普通集群模式下，以两个节点（rabbit01、rabbit02）为例来进行说明。对于Queue来说，消息实体只存在于其中一个节点rabbit01（或者rabbit02），rabbit01和rabbit02两个节点仅有相同的元数据，即队列的结构。当消息进入rabbit01节点的Queue后，consumer从rabbit02节点消费时，RabbitMQ会临时在rabbit01、rabbit02间进行消息传输，把A中的消息实体取出并经过B发送给consumer。所以consumer应尽量连接每一个节点，从中取消息。即对于同一个逻辑队列，要在多个节点建立物理Queue。否则无论consumer连rabbit01或rabbit02，出口总在rabbit01，会产生瓶颈。

3、镜像模式下

镜像模式下，将需要消费的队列变为镜像队列，存在于多个节点，这样就可以实现RabbitMQ的HA高可用性。作用就是消息实体会主动在镜像节点之间实现同步，而不是像普通模式那样，在consumer消费数据时临时读取。缺点就是，集群内部的同步通讯会占用大量的网络带宽。

Rabbitmq集群

内建集群作为RabbitMQ最优秀的功能之一，它的作用有两个：

1. 允许消费者和生产者在Rabbit节点崩溃的情况下继续运行；
2. 通过增加节点来扩展Rabbit处理更多的消息，承载更多的业务量；
   RabbitMQ的集群是由多个节点组成的，但我们发现不是每个节点都有所有队列的完全拷贝。

集群节点类型

节点的存储类型分为两种：
1、 磁盘节点
2、 内存节点
磁盘节点就是配置信息和元信息存储在磁盘上，内存节点把这些信息存储在内存中，内存节点的性能是大大超越磁盘节点的。
单节点系统必须是磁盘节点，否则每次你重启RabbitMQ之后所有的系统配置信息都会丢失。
RabbitMQ要求集群中至少有一个磁盘节点，当节点加入和离开集群时，必须通知磁盘节点。

RabbitMQ节点不完全拷贝特性

为什么默认情况下RabbitMQ不将所有队列内容和状态复制到所有节点？有两个原因：
1、 存储空间——如果每个节点都拥有所有队列的完全拷贝，这样新增节点不但没有新增存储空间，反而增加了更多的冗余数据。
2、 性能——如果消息的发布需安全拷贝到每一个集群节点，那么新增节点对网络和磁盘负载都会有增加，这样违背了建立集群的初衷，新增节点并没有提升处理消息的能力，最多是保持和单节点相同的性能甚至是更糟。
所以其他非所有者节点只知道队列的元数据，和指向该队列节点的指针。根据节点不无安全拷贝的特性，当集群节点崩溃时，该节点队列和关联的绑定就都丢失了，附加在该队列的消费者丢失了其订阅的信息，那么怎么处理这个问题呢？
这个问题要分为两种情况：
消息已经进行了持久化，那么当节点恢复，消息也恢复了；
消息未持久化，可以使用下文要介绍的双活冗余队列，镜像队列保证消息的可靠性；

RabbitMQ 对集群节点停止顺序有要求吗？

RabbitMQ 对集群的停止的顺序是有要求的，应该先关闭内存节点，最后再关闭磁盘节点。如果顺序恰好相反的话，可能会造成消息的丢失。