成长之路
在 RabbitMQ 发布三年半后，我们本周发布了 RabbitMQ 2.0。
这意味着一些重大变化。其中最重要的是我们新的可扩展存储引擎。RabbitMQ 始终为故障恢复提供持久性。但现在，无论存储了多少数据，您都可以愉快地将数据推送到 RabbitMQ 中，并且您不必担心缓慢的消费者会中断处理。随着应用程序需求的增长，RabbitMQ 可以与您一起扩展，以稳定可靠的方式。
在介绍 RabbitMQ 2.0 之前，我想重申，随着 RabbitMQ 的发展，您可以依靠我们对您（无论是大型企业、新兴创业公司还是开源社区）作为客户或最终用户的同样高度承诺。与往常一样，如果您需要帮助或商业支持，请联系 我们。
新功能
那么您可以期待什么呢？简而言之，一只更强大的兔子。特别是
- RabbitMQ 2.0 拥有全新的可扩展存储引擎。此外还有一个持久性 API。
- 对多协议消息传递的原生支持，提供更好的互操作性和更多选择
- 该版本与来自 SpringSource 的 Java 和 .NET 的一流 Spring 集成 相吻合——更多内容即将推出，例如 Grails 插件
- 未来添加 管理和监控功能 的基础，作为 rabbit-management 和其他工具的一部分
- 插件现在以即插即用二进制包的形式分发，使用起来更加容易。
与往常一样，在升级之前，请阅读 完整的发布说明。
可扩展存储意味着更高的稳定性
RabbitMQ 的愿景是消息传递应该可以正常工作。这其中的一部分是需要在大规模情况下保持稳定的行为。理想情况下，您需要一个可以启动并忘记的代理。我们新的可扩展存储引擎使我们更接近这一目标。RabbitMQ 一直拥有自己的存储引擎，其作用是持久化消息。我们使用它来提供保证最终传递、支持事务和 高可用性。
但是，在 RabbitMQ 1.x 中，代理使用了一种朴素但有效的存储模型：存储在磁盘上的每条消息也会缓存在 RAM 中。虽然这有助于提高性能，但除非您能够预测增长并相应地过度配置内存，否则它会使大规模管理变得更加困难。
使用 RabbitMQ 2.0，代理能够将消息完全刷新到磁盘。它具有更智能的缓存和分页模型。这通过根据需要将消息分页到磁盘和从磁盘分页，从而提高内存使用率。换句话说，您不必担心一个缓慢的消费者会影响整个设置，并且可以愉快地将数据推送到 RabbitMQ 中，无论已经存储了多少数据。这提高了大规模的稳定性。
我们很快会对此进行博客文章。在此期间，请尝试一下。存储爱好者可能想查看 代码库中的注释。
存储 API
RabbitMQ 现在提供了一个存储 API。这允许可插拔持久性。
RabbitMQ 包含自己的持久消息数据库，该数据库针对消息传递用例进行了优化。但是，如果您必须使用 Oracle 或 MySQL 呢？或者，如果您想尝试将 RabbitMQ 与最新最强大的 NoSQL 键值存储结合使用呢？现在您可以这样做。如果您想为您的最爱存储编写驱动程序，请联系我们。
原生多协议
我们的目标是通过简化消息传递、提供稳定的可管理服务器以及支持您需要的核心技术来降低集成成本。
RabbitMQ 自诞生之日起就支持 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 的 Webhook。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，您可以直接访问大多数消息传递系统。我们的承诺是支持客户的技术选择。摆脱锁定意味着您可以根据业务需求发展系统，而不是受供应商的产品计划和定价方案的限制。
管理和监控
我们在 RabbitMQ 的管理和整体可服务性方面做出了重大改进。
在“任何”用例中都非常可靠的管理是使消息传递非平凡的关键。很容易找到只专注于一两个用例的消息传递工具，并且做得不错。但是，在大多数情况下，提供那种重要的“正常工作”体验，然后随着时间的推移稳定运行，并且每月不会在凌晨 2 点崩溃，这很难。这需要谨慎，而且确实需要良好的管理工具。
RabbitMQ 一直提供一些 管理工具，并且社区在 扩展它们 和 使它们更加有用 以及 使它们更有用 和 相关 方面做得非常出色。但我们希望有更多功能，这意味着对代理进行更改，特别是在 API 级别。这些 API 对向最终用户展示我们认为消息传递中什么重要以及什么不重要至关重要。人们如何与工具交互以及他们如何使用工具定义了他们与该工具的关系。
在 2.0 中，您会发现支持用于收集有关 RabbitMQ 健康状况的指标和统计信息的检测，而不会显着影响性能。通常人们希望看到：当前消息速率、出现瓶颈、支持补救措施（例如，在代理繁忙时告知特定客户端降低速度）。这些功能将作为 rabbit-management 插件 和其他工具的一部分而可见。现在已经为增量添加它们奠定了基础。
告诉我们您还需要哪些管理功能
如果您有更多管理和监控功能方面的请求和想法，请联系我们。我们将继续改进 RabbitMQ 的核心功能，让它在 24/7 不间断地运行大型 Rabbit 安装变得更加容易。我们将征求社区的反馈意见，确保人们能够轻松地将管理和监控数据集成到他们喜欢的工具中。
此外，对于 SpringSource 的客户：预计每个新功能都会出现在 Hyperic 插件中，使您能够在完整的 Spring 堆栈中监控和管理 RabbitMQ 代理、队列和交换机，从而获得关于应用程序整体行为的即时上下文信息。
接下来还有什么？我该怎么做才能帮助您？
尽可能地，未来功能将分阶段推出。我们的发布理念将是渐进式的，同时保持与先前版本相同的质量关注度。我们将竭尽全力开发以下所有内容，以及更多其他内容，因此如果您想使用或帮助我们，请随时联系我们。
- 让 Rabbit 更易于使用。
- 为社区插件提供更好的支持！
- 针对 EC2 和其他地方 的云服务提供弹性消息传递。
- 新的联合样式，补充我们现有的 rabbitmq-shovel 中继。
- 更强大的 HA，以覆盖更广泛的故障转移情况。我们希望获得您的反馈！您可以通过在 rabbitmq-discuss 邮件列表 上讨论您想做的事情来帮助我们。如果您需要帮助，这也是您获得帮助的最佳场所。或者，如果您想公开最大限度地与我们交流：在 Twitter 上与我们联系，我们的账号是 @rabbitmq。
感谢您
我们要感谢两组人，他们帮助我们走到今天。首先是社区。我们要特别感谢今年测试了新持久性技术的人们。其次，我们要感谢我们的客户和多年来为 RabbitMQ 提供商业赞助的所有其他人。无论您是购买了新功能，还是与我们一起承担了真正的风险，您的贡献对我们来说都同样重要。