|
|
我的手表嗡嗡作响，在拂晓前的昏沉中，我不知道这是闹钟响了仍是复电话了。当初是早晨 4 点 45 分。我回过神来，才意想到这是一个生疏号码复电——这可不是甚么好兆头。我接通电话，是我的一个共事——他担任咱们的反对团队，为咱们的客户处置一切的出产问题。“Ryan，负疚吵醒你，当初还很早。咱们最大的客户讲演说，他们收回的申请需求两个多小时能力前往后果。咱们以为是咱们的信息零碎出问题了，但咱们不肯定接上去该怎么做。咱们需求你的帮忙。请参加咱们的电话会议。”过了一会儿，我的手表又响了，这次是闹钟。明天早上的早起可不是为了熬炼。
咱们曾经在出产环境中运转RabbitMQ将近三年了，99.5%的时间都没有问题。在此期间，咱们扩展到了 200 多个运转在数十个虚构机上的并发消费者客户端，并处置来自咱们.NET 运用顺序的数亿条动静。咱们的次要业务场景是经过 HTTP 调用 Web 办事，获得 JSON 数据或下载 PDF 文档。我会保举使用 RabbitMQ，由于咱们就用了。在大少数状况下，它都很棒，在咱们的零碎中表示良好。但这里有一个很大的问题，咱们在做架构决策时其实不知道。
咱们使用RabbitMQ来轮询调度功课的履行后果。个别的操作程序是这样的：用户经过 Web 运用顺序提交申请，后端在处置申请时向 RabbitMQ 中添加动静，消费者客户端获得动静并经过 HTTP 调用另外一个 Web 办事，将申请提交给实际处置业务逻辑的办事。而后，轮询逻辑开始接管，队列中的后续动静用于轮询处置后果。假如功课尚无履行后果，消费者将动静放回队列，等候下一次轮询尝试（等候时间可由客户配置）。等候的提早逻辑使用了存活时间（Time-To-Live，TTL）和死信队列。
咱们的非出产集群使用两个或三个节点，出产集群使用三个节点。每个集群都有一个负载平衡器，运用顺序的流量严格流经负载平衡器。在运转时，公布者和消费者使用相反的负载平衡器。
你应该知道的
在使用 RabbitMQ 三年后，假如再要写与 RabbitMQ 交相互关的代码，我一定会这样告知我本人。
一开始就请专家帮助
你能够大略花 2000 到 3000 美元从 RabbitMQ 征询公司找来专家，利用这个时机审查和验证你的假定和方案、提出问题、获得倡议并进行渎职考察，这样就能增加可能在将来泛起的问题。从久远来看，当初做出正确的决策，最有可能在将来帮你勤俭本钱。或者你也能够像咱们同样，在遇到费事时找专家帮助。
咱们使用了 EasyNetQ 或 NServiceBus
咱们的运用顺序使用了 RabbitMQ.Client 库，一些笼统库（如 EasyNetQ 和 NServiceBus）也使用了它。这些笼统库比我更理解 RabbitMQ 的底层交互。RabbitMQ 的驱动顺序相对于底层，所以你需求理解 RabbitMQ 的底层细节。假如这是你第一次使用 RabbitMQ，我包管你不会对它有任何溢美之词。
假如你想知道“为何不使用包装器库”，我能够告知你，最后的开发人员在完成接近序幕时分开了公司，他曾经使用了 RabbitMQ.Client ，而这个名目最初落到了我的手上。我没有足够的时间重构（我也没想到要把它换成包装器库）。
网络分区是个大问题
RabbitMQ 个别被部署成集群，集群由一个或多个节点组成，节点是运转 RabbitMQ 实例的办事器或容器。集群中一切的节点都必需运转彻底相反版本的 RabbitMQ。
RabbitMQ 提供了一种叫作聚簇（Clustering）的机制，这样你就能将多个 RabbitMQ 实例链接起来，成为一个逻辑 Broker。你能够将申请发送给集群中的恣意一个节点，节点汇合作公布动静或将动静发送给消费者。
节点之间经过替换对于动静、队列等的信息不停互相通讯。假如通讯间断，即便只是几毫秒，RabbitMQ 也会进入分区形态，而后它们会按照配置文件中配置的内容抉择如何处置通讯间断。默许的处置战略是 ignore，也就是间接进入分区形态，并在这类“脑裂”模式下持续运转，从而使集群堕入彻底的凌乱。这对咱们来讲几乎就是天堂（对我来讲更是如斯）。退出分区形态的独一办法是重启分区一侧的节点，而后从新衔接另外一侧，并抛弃从集群产生分区时积攒的数据。
我阅历过两种形式的网络分区：经过 Windows 更新和防火墙规定同时更新集群中一切的节点。
关于这个话题，我能够无休止地呼啸，所以我不能不让本人消停一下。正确的配置应该是将 partition_handling 战略设置为 pause_minority。当集群产生分区时，分区的一侧应该将本人封闭，防止产生脑裂。被封闭的一方持续监控集群，等候恢复通讯，并在恢复时从新参加。当初你所要做的就是确保你的代码可以正确地处置断开的衔接，这样你就有了一个至关硬朗的队列解决计划。
按照 CAP 定理，ignore 战略象征着就义统一性换取可用性，而 pause_minority 象征着就义可用性换取统一性。假如你问我的话，我以为后者是值得的。
你打算如何降级 RabbitMQ
你的 RabbitMQ 版本总归会有过期的那一天。到时分你会怎么做？持续使用不受反对的版本？创立一个新的集群？你方案怎么样将流量从遗留集群迁徙到新集群？以前曾经提到，集群中的一切节点都应该是相反的版本。假如你的方案是进行就地降级，你就会知道这将是如许辣手。
我留给你的只要问题，没有谜底。由于每一个个决策都高度依赖详细的组织和经营战略。换句话说，每集体可能都有不同的办法来解决这些问题。
假如 RabbitMQ 的动静整个丧失，你该怎么办
假如 RabbitMQ 中一切（或者三分之一）的动静丧失了，你会有多惨？RabbitMQ 是你用来保留记载的零碎吗？你有让运用顺序回到正常形态的恢复战略吗？假如你把当地办事器迁徙到云端，如何让你的 RabbitMQ 动静再次活动起来？
让公布者和消费者使用不同的衔接地址
在将来的某个时辰（多是在降级期间），你但愿可以灵敏地向不同的集群或负载平衡器公布动静或读勾销息。这是一种零危险高报答的模式，你能够及早在运用顺序中使用这类模式，将来的你会因此感激当初的你。
不停增长的日志文件将占用几十 GB 的磁盘空间
跟着时间的推移，RabbitMQ 的日志文件会增长到占用几十 GB 的磁盘空间。咱们能够使用 rabbitmqctl rotate_logs 来转动这些文件，不外也要致力使这个进程自动化，防止因“磁盘空间缺乏”致使停机。
论断
RabbitMQ 是咱们根底设施的一个巩固的组件，选择它多是一个正确的抉择。但你也应该当真看待我在本文中提出的那些问题，最少应该与你的共事和利益相干者沟通，看看应该试着解决哪些痛点。
原文链接：http://ryanrodemoyer.github.io/what-i-wish-someone-would-have-told-me-about-using-rabbitmq-before-it-was-too-late/ |
|
注册会员