截至 v3.7.0 Milestone 8，RabbitMQ 发布了一套全新的 CLI 工具 (rabbitmqctl, rabbitmq-plugins 等)，从头开始重写。这个项目我们有几个目标。

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

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

我们很高兴地宣布 RabbitMQ 3.6.0 的即时可用性，这是 broker 的一个新版本，其中包含许多新功能。在继续之前，您可以在这里获取它：/docs/download。

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

为了防止快速发布者在任何特定时刻用超过 broker 可以处理的消息来淹没 broker，RabbitMQ 实现了一种称为信用流的内部机制，该机制将由 RabbitMQ 内部的各种系统使用，以限制发布者的速度，同时允许消息消费者赶上。在这篇博文中，我们将了解信用流是如何工作的，以及我们可以做些什么来调整其配置以获得最佳行为。

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

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

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

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

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

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