随着时间的推移，我们看到社区的 邮件列表 和 Slack 频道中与 Kubernetes 相关的查询数量激增。
在 2024 年，大多数与 Kubernetes 相关的问题的答案是：使用由 RabbitMQ 核心团队构建的 Kubernetes 运算符。它融合了所有最佳实践，并且是强烈推荐的选择。
本文介绍了在 Kubernetes 上自行部署 RabbitMQ 的基础知识：哪些 Kubernetes 资源是必要的，如何确保 RabbitMQ 节点使用持久性存储，如何处理敏感值的配置，等等。
所以今天我想谈谈 RabbitMQ 性能的一些方面。有大量的变量会影响 RabbitMQ 服务器的整体性能水平，今天我们将尝试调整其中的一些变量，看看我们能看到什么。
我们在 RabbitMQ 总部面临的一个问题是，虽然我们可能对代理的工作原理有很多了解，但我们往往没有大量的经验来设计使用 RabbitMQ 的应用程序，这些应用程序需要长期可靠地无人值守地运行。我们花费大量时间在邮件列表上回答问题，并且也会进行一些咨询工作，但在某些情况下，由于用户构建应用程序并联系我们，我们才真正开始思考 RabbitMQ 的长期行为。最近，我们被促使认真思考队列的基本性能，这让我们对 Rabbit 的配置产生了一些认识。
有时，在我们的 邮件列表 和其他地方，会提出在 RabbitMQ 中使用不同的后端存储的想法。后端存储是负责将消息写入磁盘的部分（消息可以出于多种原因写入磁盘），并且经常有人建议看看如果 RabbitMQ 的后端存储被另一个存储系统替换，它会是什么样子。
这样的更改将允许目前无法实现的功能，例如带外队列浏览或分布式存储，但是消息代理（如 RabbitMQ）与通用数据库的数据存储和访问模式之间存在根本差异。事实上，RabbitMQ 故意不将消息存储在这样的数据库中。
在过去的一年中，AMQP gem 的开发实际上停滞不前，因为它的最初作者 Aman Gupta (@tmm1) 很忙。许多错误未得到解决，代码变得陈旧和过时，并且没有添加新功能或文档。
这时我开始与 RabbitMQ 团队讨论可能的合作。实际上，最初我联系了 VMware，当时我看到 Ezra Zygmuntowicz 在寻找加入他云团队的人员，但当我发现 VMware 最近收购了伦敦的 RabbitMQ 项目时，我产生了兴趣。我签署了合同，从script/console切换到 Wireshark 和 RabbitMQ Tracer，从 11 月起，我一直愉快地在 AMQP 和 AMQ-Protocol gem 上进行开发。
RabbitMQ 需要更多更好的文档。（谁不需要呢？）特别是，我们需要更多更好的入门资料，向读者介绍各种基本概念，解释它们为何重要，并激励他或她继续阅读并了解更多关于 RabbitMQ 的知识。这是该介绍的第 1 章的一个版本。欢迎您发表评论，第 2 章和第 3 章将很快发布。（您可能已经了解所有这些，但令人惊讶的是，许多人并不了解。此介绍是为他们准备的。）