RabbitMQ的脑裂踩坑 - ryanrodemoyer

22-07-17 banq

我的手表嗡嗡作响,在黎明前的昏迷中,我无法辨认这是警报还是电话。时间是凌晨 4 点 45 分:我们最大的客户报告说他们的请求需要两个多小时才能返回结果。我们认为这是因为我们的RabbitMQ消息系统。

近三年来,我们一直在为我们的生产系统运行 RabbitMQ,并且 99.5% 的时间完全没有问题。在那段时间里,我们已经扩展到 200 多个并发消费者,在十几个虚拟机上运行,​​同时协调消息处理(1 个队列到 N 个消费者),并在我们的 .NET 应用程序中处理了数亿条消息。

我们的主要用例是对另一个 Web 服务进行 HTTP 调用,以检索 JSON 数据或下载 PDF 文档。我会告诉你我推荐 RabbitMQ,那是因为我推荐。在大多数情况下,使用它非常棒,并且在我们的应用程序中表现良好。
但是,这里有一个很大的问题,所有这些都付出了我们在做出架构决策时不知道的代价。

RabbitMQ 是我们检查作业结果的轮询架构的骨干。典型的动作顺序是:用户通过 Web 应用程序提交请求,后端通过向 RabbitMQ 添加消息来处理该消息。消费者获得该消息并对另一个 Web 服务进行 HTTP 调用以实际提交请求。从那里开始,轮询逻辑接手,队列上的后续消息每条都代表了一次轮询尝试,以检索出结果。如果一项工作没有结果,消费者就会把消息放回队列,这样我们就可以把下一次轮询尝试延迟一定的时间(客户可配置)。我们的延迟逻辑使用了一个具有生存时间(TTL)和死信定义的队列网络。

我们的非开发集群使用两个或三个节点,而生产集群使用三个节点。每个集群都有一个负载平衡器,应用程序严格来说只针对负载平衡器。在运行时,发布者和消费者使用同一个负载平衡器。

在实施三年后,这是我在编写与 RabbitMQ 交互的任何一行代码之前会告诉自己的。

在开始时聘请一位专家
大概花费 2000-3000 美元(猜测),您可以聘请一家 RabbitMQ 咨询公司并获得与专家交流的时间。利用这个机会来审查和验证您的假设、计划、提问、获得建议并进行尽职调查,这样您就可以通过现在做出正确的决定来减少未来的麻烦和问题,并很可能在长期内节省资金。或者你可以采取我们的方法,在情况不妙的时候请专家帮忙。

使用像EasyNetQ或NServiceBus这样的库
我们的应用程序使用 RabbitMQ 的 RabbitMQ.Client 库,这些抽象库(如 EasyNetQ、NServiceBus)也使用它。然而,他们比我更出色,在与 RabbitMQ 在如此低的水平上进行交互方面,他们比我知道得多。来自 RabbitMQ 的驱动程序是低级的、原始的,并期望您了解有关 RabbitMQ 的细微差别。如果这是你第一次使用 RabbitMQ,那么我保证你将没有经验来理解这种细微差别。

在你问 "你为什么不使用包装库?"之前,让我告诉你。在我的案例中,我们的 RabbitMQ 项目在实施接近尾声时落到了我的头上,原开发人员离开了公司,他决定直接使用 RabbitMQ.Client 库。我没有足够的时间来进行这种交换(我也不知道我应该提出一个交换包装库的理由!)。

有这个网络分区的事情,它是一种大问题
就通用术语而言,你的 RabbitMQ 系统被称为一个集群。一个集群是由一个或多个节点组成的。一个节点只是一个运行 RabbitMQ 软件的服务器/容器。集群中的所有节点必须运行完全相同的 RabbitMQ 版本。

RabbitMQ 提供了一种称为集群的机制,因此您可以将其他 RabbitMQ 实例连接起来,以便它们作为单个逻辑代理一起运行。您可以向集群中的任何节点发出任何请求,这些节点将合作发布消息或将消息发送到消费者手中。

节点之间通过交换关于消息、队列、交换等的数据不断进行通信。如果(以及何时)该通信被中断,即使只有几毫秒,那么 RabbitMQ 将进入分区状态并查看配置文件以确定如何处理该通信中断。

默认的分区处理策略是ignore ,这意味着直接进入分区状态,并在这种 "分裂的大脑 "模式下继续前进,从而将您的集群推入完全混乱的状态。这对我们来说是地狱。退出分区的唯一方法是重新启动分区一侧的节点,这样它就会重新加入另一侧并承担他们的数据,从而丢弃它自己在集群被分区时积累的数据集。

我曾亲身经历过网络分区以两种方式发生:集群中的所有节点通过Windows更新和防火墙规则同时被更新。对Windows更新的修复是确保集群中的节点在不同时间打补丁。

我必须停下自己的脚步,因为我可以继续就这一话题滔滔不绝地说上无数的话。正确的配置是将partion_handling策略设置为pause_minority。当集群被分区时,分区的一边将简单地关闭自己,从而完全避免了大脑分裂的情况发生。关闭的那一边将继续监视集群的恢复通信,并在那时重新加入自己。现在你所要做的就是确保你的代码正确地处理断开的连接,你将拥有一个相当强大的队列解决方案。

从CAP规范来看,ignore 意味着以牺牲一致性获得可用性,而pause_minority是以牺牲可用性代价来获得一致性。如果你问我的话,后者是相当值得的。

您打算如何升级 RabbitMQ 版本?
当您的 RabbitMQ 版本已达到寿命终点时,这一天将会到来。然后您会怎么做?继续运行不支持的版本?创建一个新的集群?您将有什么计划将流量从旧集群迁移到新集群?回顾我的说明(上文),集群中的所有节点都需要运行相同的确切版本。希望你能明白,如果你的计划是就地升级节点,这将是很棘手的。

我留给你的只有问题,没有答案。这是因为每个决定都高度依赖于你的组织和运营策略。换句话说,每个人可能有一点不同的方法来解决这些问题。

如果您丢失了 RabbitMQ 中的所有消息,您有什么计划?
如果您丢失 RabbitMQ 中的所有(甚至三分之一)消息,您会有多大的损失?RabbitMQ 是您的记录系统吗?您是否有一个恢复策略来使您的应用程序恢复到正常状态?当您将您的内部服务器转移到云端时会发生什么 - 您如何让您的 RabbitMQ 消息再次流动起来?

构建您的应用程序以支持发布者和消费者的不同连接地址
在未来的某个时间点(也许是在升级期间),您将希望能够灵活地从不同的集群和/或负载均衡器独立发布和消费。这是一个零风险高回报的模式,你可以尽早在你的应用程序中建立,你会在未来拍拍屁股走人。

日志文件将增长到消耗几十千兆字节的磁盘空间
随着时间的推移,来自 RabbitMQ 的日志文件将增长到消耗数千兆字节的磁盘空间。使用 rabbitmqctl rotate_logs 轮回记录这些文件很容易,但要努力实现流程自动化,以便 "磁盘空间耗尽 "不会导致中断。



Reddit:
1、 RabbitMQ 是一个很棒的工具包,根据用例,它可能是您组织的最佳通用消息传递解决方案。即使在云部署中,我可能更喜欢在容器或 VM 中运行 RabbitMQ,而不是运行 AQS 或 Azure ServiceBus 之类的东西,如果没有其他原因,只是因为您可以在本地开发机器上快速轻松地运行 rabbit 以进行测试。
也就是说,RabbitMQ 有点特殊。由于消息传递领域的特定需求或 Erlang 的特定语义,Rabbit 中的工作方式往往与您的直觉所暗示的有所不同。集群中的一个示例,其中队列(可能)仅存在于一台机器上,因此如果分区将该机器排除在集群之外,则这些队列根本不可用。也就是说,您可以与看起来健康的节点建立活动连接,但仍然无法发送或接收消息,因为您未连接的另一个节点处于脱机状态。(您可以通过队列复制在一定程度上改善这一点,但这并非在所有队列上都可用,默认情况下也不可用)。
正确配置和调整 Rabbit 是战斗的重要组成部分,确保您有足够的受过培训的员工来解决常见错误是另一回事。

2、我已经运行RabbitMQ十多年了,有很多事情我希望在我接受它之前有人告诉我,但这些事情都不是那些。(从规模上看,我没有处理任何疯狂的事情,也许每天有5千万条消息,有大约90个队列和大约300个消费者在一个本地数据中心环境中。)

像这样的事情,集群对于并发和性能来说比它对于HA来说更有用。我最终编写了客户端连接库,它将连接到几个独立的 RabbitMQ 服务器。订阅者将同时订阅所有的服务器。编写者将随机写到任何一个服务器上。这些库将处理断开连接等问题。因此,升级到一个新的 RabbitMQ 服务器只是一次升级一个的问题,只要至少有一个服务器是有效的,客户端就可以继续运行。

像这样的事情,你不能期望消息以特定的顺序被处理,因此,以这样一种方式设置你的队列是很重要的,你会得到你所期望的东西。为了简单起见,我倾向于画一个消息处理流程图,并为每个步骤使用一个单独的队列,而不是试图在每个消息中编码状态或使用订阅者/消费者键来引导消息。这种设计的简单性使得在出现问题时更容易处理。

例如,当你有一个会使消费者崩溃的消息,而你使用的是手动ack,该消息会使_所有的消费者崩溃,直到你修复导致崩溃的东西或手动从队列中删除该消息。(我称这些消息为 "毒药"。)

像这样的事情,消费者真的应该正确地关闭他们的连接,当有人忘记这样做的时候,你可以很快地用完插座。

除非你在一个资源受限的环境中工作,否则像这样的事情你现在并不真正需要队列。在现代的云环境中,你可以直接发射lambdas进行异步处理,而忘记队列管理。

综上所述,数据库不是队列,我不会将它们互换使用。


3、我在生产环境中运行 rabbitmq 已经 6 年了,上周才第一次中断。服务器的正常运行时间超过 800 天(当然,它与公共 Internet 隔离了防火墙)。另一方面,我有几十次 Postgres 中断。并不是说 Postgres 不可靠,它坚如磐石,但我们比 RMQ 更努力地推动它。我的观点很简单,RabbitMQ 真的不难维护和使用。

 

1
猜你喜欢