随着时间的推移，我们看到社区邮件列表和 Slack 频道上与 Kubernetes 相关的查询数量飙升。
在 2024 年，大多数与 Kubernetes 相关的问题的答案是：使用 Kubernetes Operator，它由 RabbitMQ 核心团队构建。它包含了所有最佳实践，并且是强烈推荐的选项。
这篇文章解释了 RabbitMQ 在 Kubernetes 上 DIY 部署的基础知识：需要哪些 Kubernetes 资源，如何确保 RabbitMQ 节点使用持久存储，如何处理敏感值的配置等等。
今天我想谈谈 RabbitMQ 性能的某些方面。有很多变量会影响您可以从 RabbitMQ 服务器获得的总体性能水平，今天我们将尝试调整其中一些变量，看看我们能看到什么。
我们 RabbitMQ 总部面临的问题之一是，虽然我们可能非常了解 broker 的工作原理，但我们往往没有大量设计使用 RabbitMQ 且需要长期可靠、无人值守运行的应用程序的经验。我们花了很多时间回答邮件列表上的问题，并且我们在这里和那里做咨询工作，但在某些情况下，正是由于构建应用程序的用户与我们联系，我们才真正开始思考 RabbitMQ 的长期行为。最近，我们被促使认真思考队列的基本性能，这导致我们对配置 RabbitMQ 服务器有了一些认识。
有时，在我们的 邮件列表 和其他地方，出现了在 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 章即将推出。（您可能已经了解所有这些，但令人惊讶的是，很多人不了解。本介绍是为他们准备的。）