线上的rabbitmq集群经常无法访问,集群状态也不正常,查找到如下资料:
一. 环境概述
1. 3个rabbitmq node组成的集群镜像,当客户端无法连接或者连接rabbitmq超时的时候,集群的状态如下:
|
|
可以看到partitions中有内容,发生了网络分区。
2. 查看网卡状态,发现有部分丢包
|
|
3. rabbitmq日志中有如下 ERROR
|
|
二. 网络分区
RabbitMQ 会将 fabric 信息保存在 Erlang 的分布式数据库 Mnesia 中。而和网络分区相关的许多细节问题都和 Mnesia 的行为相关。
1. 网络分区的探测
Mnesia 判定某个 node 失效的根据是,如果其他 node 无法连接该 node 的时间达到 1 分钟以上(详情请参 考 net_ticktime 的 说明)。当这两个 node 恢复到能联系上的状态时,都会认为对端 node 已 down 掉了,此时 Mnesia 将会判定发生了网络分区。这种情况会被记录进 RabbitMQ 的日志文件中,如下:
|
|
RabbitMQ node 会记录下在当前 node 运行期间是否发生过这个 event ,并会通过 rabbitmqctl cluster_status 命令和管理插件将该信息暴露出来。 在正常情况下,rabbitmqctl cluster_status 显示结果中的 partitions 部分为空列表 []:
|
|
如果发生了网络分区,那么会有如下信息显示出来:
|
|
2. 当网络分区发生时
当发生网络分区时,分区的两侧(或者多侧)均能够独立的进化,同时认为另外一侧已经处于不可用状态。其中 queue、binding、exchange 均能够在各个分区中创建和删除。而由于网络分区而被割裂的==镜像队列==,最终会演变成每个分区中产生一个 master ,并且每一侧==均能独立进行工作==。其他未定义和奇怪的行为也可能发生。
需要额外注意的是, 当网络分区的情况得到恢复后,上述问题仍旧存在,直到你采取行动进行修复。
3. 由于 挂起/恢复 而导致的分区
当我们谈及“网络”分区时,其真正的意思是指:在任何情况下,同一个集群中的 node 在没有 down 掉的情况下,相互之前的通信被中断的情况。除了网络失效导致的分区外,当挂起和恢复集群 node 所在机器的整个 OS ,同样能够导致分区的发生。这种情况下,被挂起的 node 并不认为自己已经失效了,或者被停掉了,但是同一集群中的其他 node 会认为是这样。
你能通过合上笔记本盖子的方式,挂起运行在笔记本上的集群中的一个 node ,但更常见的情况是由于虚拟机被监管程序挂起导致。尽管允许将 RabbitMQ 集群运行在虚拟化环境中,你需要确保 VM 不会被在运行中被挂起。需要注意的是,一些虚拟化技术特性,例如将 VM 从一个 host ==迁移==至另外一个 host 时,会导致 VM 被挂起。
由于挂起导致的网络分区,在恢复的时候行为是不对称的。被挂起的 node 将有可能不会认为其他 node 已经 down 掉,但是会被集群中的其他 node 看作 down 掉。这个行为对于 pause_minority 模式来说有特殊含义。
4. 从网络分区中恢复
为了从网络分区中恢复,首先要选择你最相信的一个分区。选中的分区将会作为“权威机构”被 Mnesia 使用。任何发生在未被选中分区中的变更将会丢失。 停止其他分区的所有 node ,之后再重新启动它们。当它们重新加入到集群中时,它们将会从受信分区恢复自身的状态。最后,你同样应该重启受信分区中的所有 node 以便清除警告信息。 一种更简单的方式是,停止整个集群,再==重启集群==。如果你是按照这种方式来恢复网络分区的,那么请确保你所启动的第一个 node 为受信分区中的 node 。
5. 自动处理网络分区
RabbitMQ 同样提供了三种方式来自动处理网络分区问题:pause-minority 模式,pause-if-all-down 模式和 autoheal 模式
在 pause-minority
模式中,一旦发现有其他 node 失效,RabbitMQ 将会自动停止“特定”集群中的所有 node ,只要确定该集群为少数派集群(即少于或等于半数 node 数)。可以看出,这种策略是选择了 CAP 理论中的分区容错性(P),而放弃了可用性(A)。这种策略保证了当发生网络分区时,最多只有一个分区中的 nodes 会继续工作。而处于少数派集群中的 node 将在分区发生的开始就被停止,在分区恢复后重新启动。
在 pause-if-all-down
模式中,RabbitMQ 会自动停止集群中的 node ,只要其无法与列举出来的任何 node 进行通信 。这和上一个模式比较接近,但是该模式允许管理员来决定根据哪些 node 做判定,而不直接取决于与上下文环境。例如,如果集群是由位于数据中心 A 的两个 node ,以及位于数据中心 B 的两个 node 构成的,并且两个数据中心之间的连接断开了,那么 pause-minority 模式会导致所有的 node 被停掉。而对于 pause-if-all-down 模式来说,如果管理员列举出来的 node 是数据中心 A 中的那两个 node ,那么将只有数据中心 B 里的两个 node 被停掉。需要注意的是,可能存在列举出来的多个 node 本身就处于无法通信的不同分区中:在这种情况下,将不会有任何 node 被停掉。这也就是为什么存在一个额外的 ignore/autoheal 参数来进一步指示如何从分区中恢复。
在 autoheal
模式中,RabbitMQ 将在发生网络分区时,自动决议出一个胜出分区,并重启不在该分区中的所有 node 。与 pause_minority 模式不同的是,autoheal 模式是在分区结束阶段(已经形成稳定的分区)是起作用,而不是在分区开始阶段(刚刚开始分区)。
胜出分区是获得最多客户端连接的那个分区(或者如果产生了平局,则选择拥有最多 node 的那个;如果仍旧是平局,则随机选择一个分区)。
你可以在配置文件中设置 cluster_partition_handling 项的值为上述任何值:
|
|
需要明确的一点是,允许 RabbitMQ 自行处理网络分区问题并不代表你可以认为该问题就不存在了。无论何时网络分区都会导致 RabbitMQ 集群产生问题。你只是在可能遇到何种层次的问题上面多了些选择。正如在本文开始处所说的,如果你打算基于不可靠连接接入 RabbitMQ 集群,你应该使用 federation 或 shovel 。
三. 恢复策略选择
ignore
- 要求你所在的网络环境非常可靠。例如,你的所有 node 都在同一个机架上,通过交换机互联,并且该交换机还是与外界通信的必经之路。 并且你不想因为集群中的任意 node 失效而导致集群停工,即使集群中有 node 真的失效(默认策略是ignore )。pause_minority
- 你的网络环境可能没有那么可靠。例如,你在 EC2 上构建了一个横跨 3 个 AZs 的集群,并且你假定同一时刻最多只有一个 AZ 会失效。在这种场景下,你希望剩余的 2 个 AZs 能够继续工作,直到失效 AZ 恢复后,位于其中的 node 重新自动加入集群,并且不会造成任何混乱。autoheal
- 你的网络环境可能是不可靠的。你会更加关心服务的可持续性,而非数据完整性。你可以构建一个包含 2 个 node 的集群。
综上这里我们选择 pause_minority 策略
四. 参考资料
Clustering and Network Partitions
RabbitMQ 之 Clustering 和 Network Partition(翻译)