RabbitMQ集群并处理失败

转载的别人的转载，找不到原创链接，所以贴个百度🔗

---

RabbitMQ集群

让rabbitmq变成高可用性的2种方法：

• 设置rabbit集群
• 扩展程序的规模以提升性能

rabbitmq 内建集群的设计用于完成2个目标：

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

rabbitmq通过Erlang 提供的开放电信平台(Open Telecom Platform,OTP)分布式通信框架来巧妙的解决上面2个问题。

• 当你失去一个rabbit节点，同时客户端能够重新连接到集群中的任意其他节点并继续生产或者消费消息，就像什么都没发生过一样。
• 当一个rabbit集群节点崩溃时，该节点上队列的消息也会消失，这是因为rabbit默认不会将队列的内容复制到整个集群上。如果不进行特殊的配置，这些消息仅存在于队列所属的那个节点上。

集群架构

rabbitmq 会始终记录以下4种类型的内部元数据：

1. 队列元数据---队列名称和它们的属性(是否可持久化，是否自动删除)
2. 交换器元数据---交换器名称，类型和属性(可持久化等)
3. 绑定元数据---一张简单的表格展示了如何将消息路由到队列
4. vhost元数据---为 vhost 内的队列，交换器和绑定提供命名空间和安全属性

在单一节点内，rabbitmq会将所有的这些信息存储到内存中，同时将那些标记位可持久化的队列和交换器(以及它们的绑定)存储到磁盘上。存储到磁盘上可以确保队列和交换器在重启rabbit节点后重新创建。当你引入集群时，rabbitmq需要重新追踪新的元数据类型：集群节点位置，以及节点与已记录的其他类型元数据的关系。集群也提供了选择：将元数据存储到磁盘上(独立节点的默认设置)，或者仅存储在 RAM 中。

集群中的队列

在将2个节点组成集群的那一刻，事情将发生巨大的变化：不是每一个节点都有所有队列的完全拷贝。在单一节点设置中，所有关于队列的信息(元数据，状态和内容)都完全存储在该节点上。但是如果在集群中创建队列的话，集群只会在单个节点而不是所有节点上创建完整的队列信息(元数据，状态，内容)。结果是只有队列的所有者节点知道队列的所有信息。所有其他非所有者节点只知道队列的元数据和指向该队列存在的那个节点的指针。因此，当集群节点崩溃时，该节点队列和管理的绑定就都消失了。附加在那些队列上的消费者丢失了其订阅信息，并且任何匹配该队列绑定信息的新消息也都丢失了。

别担心，你可以让消费者重新连到集群并重新创建队列。这种做法仅当队列最开始没有被设置成可持久化时才是可行的。如果重新创建的队列被标记为持久化了，那么在其他节点重新声明它们的话就会得到一个404 NOT_FOUND 错误。这样确保了当节点失败恢复后加入集群，该节点上的队列消息不会丢失。想要该指定队列重回集群的唯一方法是恢复故障节点。但是如果消费者尝试重建的队列是不可持久化，那么重新声明就会成功，你可以准备重新绑定它们并传输数据。

为什么默认情况下rabbitmq不将队列内容和状态复制到所有的节点上呢？

• 存储空间：如果每个集群节点都拥有所有队列的完整拷贝，那么添加新的节点不会给你带来更多存储空间。举个例子，如果一个节点可以存储1GB的消息，那么添加两个节点指挥给你带来两个一模一样的1GB的消息的拷贝。
• 性能 : 假如那样的话，消息的发布需要将消息复制到每个节点上。对于持久化的消息来说，每一条消息都会触发磁盘活动。

通过设置集群中的唯一节点来负责任何特定队列，只有该负责节点才会因队列消息而遭受到磁盘活动的影响。其他所有的节点需要将接收到的该队列的消息传递给该队列的所有者节点。因此，往rabbit集群添加更多的节点意味着你讲拥有更多的节点传播队列，这些新增的节点为你带来了性能的提升。

分布交换器

 事实上，不同于队列那样拥有自己的进程，交换器说到底只是一个名称和一个队列绑定列表。当你的消息发布到交换器时，实际上是由你所连接到的信道将消息上的路由键同交换器的绑定列表进行比较，然后路由消息。正是信道按照绑定匹配的结果，将消息路由到队列。这是为什么呢？理解信道是真正的路由器这一点很重要，因为这解释了为什么交换器不会像集群中的队列那样受到相同的限制。

注意：理解rabbitmq背后的消息路由工作机制的方法是把每个队列想象成节点上运行的进程，每个进程拥有自己的进程ID(PID)。交换器不过是路由模式列表和匹配消息应发往的队列进程ID的列表。当发布的消息匹配了交换器中的绑定规则时，实际上是由信道完成了匹配工作，并在匹配之后建立到队列PID的连接，然后将消息传送过去。队列的进程ID本质上是在集群中的erlang 地址。

由于交换器只不过是一张查询表，而非实际上的消息路由器，因此将交换器在整个集群中进行复制会更加简单。举例来说，当创建一个新的交换器时，rabbitmq所要做的是将查询表添加到集群中的所有节点上。这时，每个节点上的每条信道都可以访问新的交换器了。因此，相对于默认情况下队列的完整信息存储于集群中的单一节点来说，集群中的每个节点拥有每个交换器的信息。就可用性来说，这非常棒，因为这意味着你不用担心在节点故障时重新声明交换器。只需要让故障的节点上的生产者重新连接到集群上，它们就能立即开始往交换器上发布消息了。

AMQP的 basic.publish 命令不会返回消息的状态。这意味着当前信道节点崩溃时信道仍然可能在路由消息，而生产者已经继续创建下一条消息了。在这种情况下，你将承受丢失消息的风险。解决的方法是使用 AMQP 事务，在消息路由到队列之前它会一直阻塞；或者使用发送方确认模式来记录连接中断时尚未被确认的消息。

是内存节点还是磁盘节点

每个rabbitmq节点，不管是单一节点系统或者是庞大集群的一部分，要么是内存节点，要么是磁盘节点。

内存节点将所有的队列，交换器，绑定，用户，权限和vhost的元数据定义都仅存储在内存中。而磁盘节点则将元数据存储在磁盘中。

单节点系统允许磁盘类型的节点；否则，每次你重启rabbit之后，所有关于系统的配置信息都会丢失。不过在集群中，你可以选择配置部分节点为内存节点。因为它使得队列和交换器声明之类的操作更加快速。

当在集群中声明队列，交换器或者绑定的时候，这些操作会直到所有集群节点都成功提交元数据变更之后返回。对于内存节点来说，这意味着变更写入内存；对于磁盘节点来说，这意味着昂贵的磁盘写入操作，直到完成之后，节点才能说：'完事了'。

假设你有5个节点的集群，并且所有节点都是磁盘节点，则你必须得等待所有这5个节点将元数据写入磁盘后，队列声明操作才能返回。对于队列长存的服务器来说没什么。但如果你正在处理繁重的rpc呢？如果每个rpc客户端正创建和销毁每秒数以百计的应答队列，你就会明白磁盘节点会降低性能。内存节点可以提供出色的性能，和磁盘节点能够保障集群配置信息免于重启。

rabbitMQ只要求在集群中至少有一个磁盘节点，所以其他节点都可以是内存节点，记住，当节点加入或者离开集群时，它们必须要将变更通知到至少一个磁盘节点。如果只有一个磁盘节点，而且不凑巧的是它又刚好崩溃了，那么集群可以继续路由消息，但是不能做以下的操作：

创建队列、创建交换器、创建绑定、添加用户、更改权限、添加或者删除集群节点

换句话说，如果集群中唯一的磁盘节点崩溃的话，集群仍然可以保持运行，但是直到该节点恢复到集群之前，你无法更改任何东西。解决方案是在集群中设置2个磁盘节点，因此它们中至少有一个是可用的，能够在任何时刻保持元数据的变更。只有一个需要所有的磁盘节点必须在线的操作是添加或者删除集群节点。当内存节点重启后，它们会连接到预先配置的磁盘节点，下载当前集群元数据拷贝。如果你只将2个磁盘节点中的一个告诉了内存节点，而不凑巧的是当前内存节点供电中断时该磁盘节点页发生故障的话，那么内存节点在重启之后就无法找到集群节点了。

所以当添加内存节点时，确保告知其所有的磁盘节点(内存节点唯一存储到此的元数据信息是机器中磁盘节点的地址)。只要内存节点可以找到至少一个磁盘节点，那么它就能在重启后重新加入集群。