RabbitMq之集群

让RabbitMq变成高可用性有两种方式：一种是设施Rabbit集群，另一种为扩大程序规模。接下来讲述RabbitMq集群
RabbitMq内建集群用于完成两个目标：

• 允许生产者和消费者在Rabbit节点崩溃的情况下继续运行
• 通过添加更多的节点来线性扩展消息通信吞吐量
  当你失去一个rabbitmq节点，同时客户端能重新连接到集群中，并继续生产和消费消息。
  当一个rabbit集群节点崩溃时，该节点上队列的消息也会消失。rabbitMq默认不会将队列上的内容复制到整个集群中。

集群架构

RabbitMq会始终记录一下四种类型的内部元数据：

• 队列元数据：队列名称和他的属性（是否可持久化，是否自动删除）
• 交换器元数据：交换器名称、类型和属性（可持久化等）
• 绑定元数据：一张简单的表格展示了如何将消息路由到队列
• vhost元数据：为vhost内的队列、交换器和绑定提供命名空间和安全属性

在单一节点内，RabbitMq会将这些绑定信息存储在内存中，同时将那些标记为可持久化的队列和交换器存储到硬盘上。硬盘可确保队列和交换器重启RabbitMQ几点后 重新创建。
引入集群后，RabbitMq需要追踪新的元数据类型：集群节点位置，以及节点与已记录的其他类型元数据的关系。同时也可将元数据存储到磁盘上。

集群中的队列

RabbitMq集群中，不是每一个节点都有所有队列的完全拷贝，单一节点中所有关于队列的信息（元数据、状态和内容）都完全存储在该节点上。若在集群中创建队列的话，集群只会在单一节点而不是所有节点创建完整的队列信息,只有队列的所有者知道队列的信息。因此当集群节点崩溃时，该节点的队列个关联的绑定也就小时了，附加在队列上的消费者丢失了其订阅信息，且任何匹配该队列的绑定信息的新消息也都丢失了。

未做持久化时，可让消费者重新连接到集群并重新创建队列。若重新创建队列被标记成持久化了，则在其他节点上重新声明他们的话，会报404 NOT_FOUND的错误。这样确保了失败节点回复后加入集群，该节点上的队列消息不会丢失。想要指定队列重新回到集群的唯一方式就是恢复故障节点。

分布交换器

交换器只是一个名称和队列绑定列表。当消息发布到交换器时，实际上是有你所连接的信道将消息上的路由键同交换器的绑定列表进行比较，然后路由消息到队列。
相对于默认情况下队列的完整信息存储到集群中的单一节点来说，集群中的每个节点都拥有每个交换器的所有信息，因此不用再担心再节点故障时，重新声明交换器，只需让故障节点上的生产者重新连接到集群上。

AMQP的basic.publish命令不会返回消息的状态。意味着当信道节点崩溃时，信道仍然可能在路由消息，而生产者已经继续创建下一条消息了，此时将有消息丢失的风险。解决办法是使用AMQP事务，在消息路由带队列之前他会一直被阻塞；或者使用发送发确认模式来记录连接中断时，尚未被确认的消息。当与交换器在集群中完全复制的这一事实相结合时，事务模式和发送方确认模式都能保证应用程序一直发布而不丢失消息。

内存节点和磁盘节点

• 内存节点：将所有的队列、交换器、绑定、用户、权限和vjihost的元数据定义都金存储在内存中；
• 磁盘节点：将元数据存储在磁盘中
  单节点系统只允许磁盘类型的节点；否则，每次重启rabbitMq后所有系统配置信息都会丢失。
  
  在集群中声明队列、交换器或者绑定的时候，这些操作会知道所有集群节点都成功提交元数据变更后才返回。
  RabbitMq只要求集群中至少有一个磁盘节点。所有节点可以是内存节点。记住，当节点离开集群时，他们必须要将该变更通知到至少一个磁盘节点。若集群中唯一磁盘节点崩溃，集群仍可运行，但是直到该节点恢复到集群前，你无法更改任何东西。解决方案是集群中 设置两个磁盘节点，因此至少有一个是可用的，能再任何时候保存元数据变更。
  当内存节点重启后，它们会连接到预先配置的磁盘节点，下载当前集群元数据的备份拷贝。若你只将两个磁盘节点中的一个告诉了内存节点，而不凑巧的是当内存节点供电中断时改磁盘节点也发生故障的话，那么内存节点在重启后就无法找到集群了。因此当添加内存节点时，确保告知其所有磁盘节点（内存唯一存储到磁盘的元数据信息是集群中磁盘节点的地址）。只要内存节点可以找到至少一个磁盘节点，那么他就能再重启后，重新加入集群。