成长
在 RabbitMQ 推出三年半后，我们本周发布了 RabbitMQ 2.0。
这意味着一些重大变化。其中最重要的是我们新的可伸缩存储引擎。RabbitMQ 一直为故障恢复提供持久化。但现在，您可以随意将数据推送到 RabbitMQ，而无需担心已存储的数据量，也不必担心缓慢的消费者会干扰处理。随着您的应用程序需求增长，RabbitMQ 可以稳定可靠地与您一起扩展。
在介绍 RabbitMQ 2.0 之前，我重申一下，随着 RabbitMQ 的发展，您可以指望我们对您作为客户或最终用户的同等高度的承诺，无论您是大型企业、下一代初创公司还是开源社区。一如既往，如果您需要帮助或商业支持，请 联系我们。
新功能
那么，您可以期待什么？简而言之，一个更强大的兔子。特别是
- 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 的核心添加更多内容，使其更容易全天候、无限期地运行大型 Rabbit 安装。我们将寻求社区的反馈，以确保管理和监控数据流能够真正轻松地集成到您喜欢的工具中。
此外，对于 SpringSource 客户：期望每个新功能也会出现在 Hyperic 插件中，使您能够在整个 Spring 堆栈中监控和管理 RabbitMQ 代理、队列和交换机，从而获得关于应用程序整体行为的即时上下文智能。
接下来还有什么？我该如何提供帮助？
尽可能地，未来功能将分阶段推出。我们的发布理念将是演进式的，同时保持与之前版本相同的质量关注度。我们将努力完成所有以下项目以及更多项目，因此如果您想使用它们或提供帮助，请随时与我们联系。
- 让 Rabbit 更易于使用。
- 为社区插件提供更好的支持！
- 为云服务提供弹性消息传递，支持 EC2 及其他平台
- 新的联邦样式，补充我们现有的 rabbitmq-shovel 中继
- 更好的高可用性，以覆盖更广泛的故障转移场景。我们希望获得您的反馈！您能提供的最大帮助是在 rabbitmq-discuss 邮件列表上讨论您的需求。如果您需要帮助，那里也是最好的地方。或者，如果您想公开最大化：在 Twitter 上与我们联系，我们的账号是 @rabbitmq
谢谢
我们要感谢两类人让我们走到今天。首先是社区。我们特别要感谢那些在今年全年测试了新持久化技术的各位。其次，我们要感谢我们的客户以及多年来在商业上赞助 RabbitMQ 的所有人。无论您是购买了新功能，还是冒着真正的风险与我们合作，您的贡献对我们来说都同样重要。