不断成长

2010年8月27日 ·9 分钟阅读

Alexis Richardson

在我们推出 RabbitMQ 大约三年半之后，本周我们发布了 RabbitMQ 2.0。

这意味着一些重大的变化。其中最重要的是我们全新的可扩展存储引擎。 RabbitMQ 一直为故障恢复提供持久性。但现在，您可以愉快地将数据推送到 Rabbit 中，而无需考虑已经存储了多少数据，并且您无需担心慢速消费者会扰乱处理。随着您的应用程序需求的增长，Rabbit 可以以稳定、可靠的方式与您一起扩展。

在介绍 RabbitMQ 2.0 之前，请允许我重申，随着 Rabbit 的发展，无论您是大型企业、下一代初创公司还是开源社区，您都可以像客户或最终用户一样信赖我们对您的高度承诺。与往常一样，如果您需要帮助或商业支持，请联系我们。

新功能

那么您可以期待什么呢？简而言之，一只功能更强大的兔子。特别是：

RabbitMQ 2.0 拥有全新的可扩展存储引擎。还有一个持久性 API。
对多协议消息传递的本机支持，提供更好的互操作性和更多选择
此版本与 SpringSource 的 Java 和 .NET 的一流 Spring 集成同时发布 - 更多功能即将推出，例如 Grails 插件
未来更多管理和监控功能的基础，作为 rabbit-management 和其他工具的一部分
插件现在以即插即用的二进制包形式分发，使它们更容易使用。

与往常一样，在升级之前，请阅读完整发行说明。

可扩展存储意味着更高的稳定性

Rabbit 的愿景是消息传递应该开箱即用。这部分来自于大规模稳定行为的需求。您理想情况下需要一个可以启动并忘记的代理。我们新的可扩展存储引擎使我们更接近这一目标。 RabbitMQ 一直拥有自己的存储引擎，其工作是持久化消息。我们使用它来提供有保证的最终交付、对事务的支持以及高可用性。

但是，在 RabbitMQ 1.x 中，代理使用了一种朴素但有效的存储模型：存储在磁盘上的每条消息也会缓存在 RAM 中。虽然这有助于提高性能，但除非您能够预测增长并相应地过度配置内存，否则会使管理规模变得更加困难。

在 RabbitMQ 2.0 中，代理能够将消息完全刷新到磁盘。它具有更智能的缓存和分页模型。这通过将消息分页到磁盘和从磁盘分页来提高内存使用率，根据需要。换句话说，您不必担心一个慢速消费者会扰乱您的整个设置，并且可以愉快地将数据推送到 Rabbit 中，而无需考虑已经存储了多少数据。这提高了大规模的稳定性。

我们很快会写一篇关于此的博客。与此同时，请试用一下。存储爱好者可能想查看代码库中的注释。

存储 API

RabbitMQ 现在提供了一个存储 API。这允许可插拔的持久性。

RabbitMQ 包含自己的持久消息数据库，该数据库针对消息传递用例进行了优化。但是，如果您必须使用 Oracle 或 MySQL 怎么办？或者，如果您想尝试将 RabbitMQ 与最新和最出色的 NoSQL 键值存储结合使用，该怎么办？现在您可以做到这一点。如果您想为自己喜欢的存储编写驱动程序，请联系我们。

原生多协议

我们的目标是通过简化消息传递、提供稳定的可管理服务器以及支持您所需的主要技术来降低集成成本。

自 Rabbit 诞生以来，它就一直支持 AMQP。 RabbitMQ 最初支持 AMQP 0-8，并且随着 AMQP 的发展，在分支上添加了对 0-9-1 的支持。 AMQP 0-9-1 不到 50 页，使其非常易读且树状友好。更短、更简单的协议更容易实施和验证，这对于希望从多个供应商获得 AMQP 的客户来说非常重要。

在 2.0 版本中，RabbitMQ 现在可以直接在其核心中支持多种协议 - 预集成了 AMQP 0-8 和 0-9-1。此外，RabbitMQ 扩展为各种协议提供支持，包括 XMPP、STOMP、HTTP JSON/RPC、HTTP 的 pubsub（例如 Google 的 PubSubHubBub）和 SMTP。

如果您想要更多协议的支持，或者对我们未来的计划有疑问，请联系我们；例如：为未来版本的 AMQP 提供安全的演进路径。

更好的插件支持

我们的目标是为广泛的消息传递应用程序提供支持，而不会使代理变得臃肿和复杂。插件是实现这一目标的关键。它们使我们和您能够扩展和自定义 RabbitMQ 的功能。以前，您只能通过从源代码构建来加载我们的插件。在 2.0 版本中，我们分发预编译的插件。将它们放入 RabbitMQ 可以加载它们的目录中即可。

为了了解您可以做什么，我建议您看看 Tony Garnock-Jones 在上次 Erlang Factory 上做的精彩的插件介绍。祝贺 Jon Brisbin 成为第一个为 RabbitMQ 2.0 创建插件的人，在不到一两天的时间内，添加了 RabbitMQ 的 Webhooks。 Matthew Sackman 和 Tony Garnock-Jones 也创建了一些自定义交换器。请注意，其中许多是演示和示例，因此通常的注意事项适用。

SpringSource 在 Java 和 .NET 中的一流 Spring 支持

我们认为，无论您为哪个应用程序平台进行开发，消息传递都应该直观。在 Java 中，明显的领导者是 Spring，我们是 Vmware 的 SpringSource 部门的一部分，因此添加成熟的 Spring 支持是必须的。我们非常感谢 SpringSource 团队的 Mark Fisher 和 Mark Pollack 将其变为现实。随着 RabbitMQ 2.0 的发布，我们向整个社区强调 Spring 支持已正式可用。

如果您是 .NET 用户，您已经能够将 RabbitMQ 作为 Windows 服务运行，并从 .NET 语言和 WCF 中使用它多年了。如果您想从基于 Windows 的应用程序（例如 Excel）向用 Java 或数百个其他 AMQP 集成点编写的后端服务进行消息传递，这非常棒。现在，借助 Spring.NET 支持，我们还为您提供了一个通用的应用程序开发模型，该模型在 Java 和 .NET 中同样适用。

将所有内容整合在一起：更多选择自由

我们认为，协议互操作性和更轻松的集成为您提供了选择。如果您正在为企业部署，并且需要将 RabbitMQ 连接到不支持 AMQP 的旧版企业消息传递系统，该怎么办？ Spring 为您提供了一条前进的道路。借助 Spring Integration，您可以一流地访问大多数消息传递系统。我们的承诺是支持客户对技术的选择。免受供应商锁定的自由意味着您可以期望根据业务需求发展您的系统，而不是受到供应商产品计划和定价方案的限制。

管理和监控

我们对 Rabbit 的管理和整体可维护性进行了重要改进。

在“任何”用例中，坚如磐石的管理是使消息传递变得不平凡的核心。很容易找到只关注一两个用例的消息传递工具，并且做得还不错。但是在大多数情况下一次提供所有重要的开箱即用体验，然后在一段时间内稳定运行，而不是每月凌晨 2 点崩溃一次，这很难。这需要小心，并且确实需要良好的管理工具。

Rabbit 一直提供一些用于管理的工具，社区在扩展它们和使它们更有用以及使它们更相关方面做得非常出色相关。但是我们想要更多功能，这意味着要更改代理，尤其是在 API 级别。这些 API 对于向最终用户展示我们认为重要的消息传递内容以及不重要的内容至关重要。人们与工具互动的方式以及他们使用工具的方式定义了他们与该工具的关系。

在 2.0 中，您将找到对仪表盘的支持，用于收集有关 Rabbit 健康状况的指标和统计信息，而不会显着影响性能。通常，人们希望看到：当前消息速率、新兴瓶颈，以及对补救措施的支持，例如在代理繁忙时告诉特定客户端降低速度。这些功能将作为 rabbit-management 插件和其他工具的一部分变得可见。现在已经为它们的逐步添加奠定了基础。

告诉我们您还想要什么管理功能

请联系我们，提出更多管理和监控功能的要求和想法。我们将向 RabbitMQ 的核心添加更多功能，使其更容易 24/7 全天候无限期地运行大型 Rabbit 安装。我们将寻求社区的反馈，以确保人们可以非常轻松地将管理和监控信息集成到他们喜欢的工具中。

此外，对于 SpringSource 客户：期望每个新功能也会出现在 Hyperic 插件中，使您能够在完整的 Spring 堆栈中监控和管理 RabbitMQ 代理、队列和交换器，从而立即获得关于应用程序整体行为的上下文智能。

接下来还有什么以及我如何提供帮助？

未来功能将尽可能分阶段出现。我们的发布理念将是渐进式的，同时保持与以前版本相同的质量重点。我们将非常努力地处理以下所有项目以及更多项目，因此如果您想使用它们或提供帮助，请联系我们

使 Rabbit 更易于使用。
更好地支持社区插件！
适用于 EC2 和其他地方云服务的弹性消息传递
新的联邦风格，补充我们现有的 rabbitmq-shovel 中继
更好的 HA，以涵盖更广泛的故障转移情况我们希望您的反馈！您能提供的最佳帮助方式是在 rabbitmq-discuss 邮件列表上谈论您想做什么。这也是您在需要帮助时获得最佳帮助的地方。或者，如果您想最大限度地公开：在 Twitter 上与我们交谈，我们的 Twitter 账号是 @rabbitmq

感谢您

我们要感谢两组人让我们走到今天。首先是社区。我们尤其要感谢那些在今年全年测试新持久性技术的人们。其次，我们要感谢我们的客户和多年来商业赞助 RabbitMQ 的所有人。无论您是购买了新功能，还是与我们一起承担了真正的风险，您的贡献对我们来说都同样重要。