65 篇帖子 标记为 “新功能”

RabbitMQ Java 客户端 4.0 版本 带来了对运行时指标的支持。这对于了解客户端应用程序的运行状况特别有用。让我们看看如何启用指标收集，以及如何在 JMX 甚至 Spring Boot 应用程序中监控这些指标。

RabbitMQ 团队很高兴地宣布 RabbitMQ Java 客户端 4.0 版本的发布。这个新版本没有引入任何破坏性更改，并带来了一系列有趣的新功能。

我们很高兴地宣布 RabbitMQ 3.6.0 的立即发布，这是一个新版本的 Broker，其中包含大量新功能。在继续之前，您可以在这里获取它：/docs/download。

此版本在 Broker 功能、我们贡献者的开发环境和安全性方面带来了许多改进。让我们来看看其中一些最重要的改进。

一段时间以来，人们一直在寻找使用 RabbitMQ 实现延迟消息传递的方法。到目前为止，公认的解决方案是使用 消息 TTL 和 死信交换机 的组合，如 NServiceBus 在此处所实现的那样。在考虑了一段时间的开箱即用解决方案后，我们有机会将其实现为插件。引入 RabbitMQ Delayed Message Plugin。

“我的队列使用了多少内存？” 这是一个容易提出的问题，但回答起来有点复杂。RabbitMQ 3.4 使您可以更清楚地了解队列如何使用内存。这篇博文将对此进行一些讨论，并总体上解释队列内存的使用情况。

RabbitMQ 3.3 的目标之一是您应该能够更轻松地找到运行系统中的瓶颈。旧版本的 RabbitMQ 可以让您看到您受到速率限制，但不容易让您看到原因。在这篇博文中，我们将讨论 3.3 版本中的一些新性能指标。

在开始之前我警告你：这是另一篇关于 RabbitMQ 3.3 中与性能相关的更改的冗长博文。还在跟我们一起吗？很好。

所以在上一篇文章中，我提到了“我将在以后的博文中谈论的新功能”。该功能是消费者偏好。

好吧，我们昨天已经解决了坏消息，所以今天让我们谈谈（一些）好消息：某些类型的发布和消费现在快得多，尤其是在集群中。

什么？又一篇“破坏性更改”的文章？嗯，是的，但希望这应该比前一篇更容易处理。但是 RabbitMQ 3.3.0 中有足够多的稍微不兼容的更改，值得在此处列出它们。

我们架构中的不同服务将需要一定数量的资源才能运行，无论是 CPU、RAM 还是磁盘空间，我们都需要确保我们有足够的资源。如果我们不对服务器将要使用的资源数量设置限制，那么在某些时候我们会遇到麻烦。如果您的数据库耗尽文件系统空间，您的媒体存储空间被图像填满并且永远不会将它们移动到其他地方，或者您的 JVM 耗尽 RAM，就会发生这种情况。如果您没有用于使旧备份过期/删除的策略，即使您的备份解决方案也会成为问题。好吧，队列也不例外。我们必须确保我们的应用程序不会允许队列永远增长。我们需要制定一些策略来删除/逐出/迁移旧消息。