RabbitMQ HTTP API 的新型响应式客户端
RabbitMQ 团队很高兴宣布发布 HOP 2.0 版本,HOP 是 RabbitMQ HTTP API 的 Java 和其他 JVM 语言客户端。此新版本引入了基于 Spring Framework 5.0 WebFlux 的新型响应式客户端。
RabbitMQ 团队很高兴宣布发布 HOP 2.0 版本,HOP 是 RabbitMQ HTTP API 的 Java 和其他 JVM 语言客户端。此新版本引入了基于 Spring Framework 5.0 WebFlux 的新型响应式客户端。
RabbitMQ Java 客户端 4.0 版本 带来了对运行时指标的支持。这对于了解客户端应用程序的行为方式特别有用。让我们看看如何启用指标收集以及如何在 JMX 甚至 Spring Boot 应用程序中监控这些指标。
这篇博文是为 2015 年发布的 RabbitMQ 3.5 撰写的。虽然有些部分仍然适用,但其中有很多过时的信息。例如,RabbitMQ 4.0 不再支持队列镜像,“将消息分页到磁盘”也不再是 RabbitMQ 必须做的事情,因为消息几乎总是立即持久化到磁盘。
为了防止快速发布者向代理发送的消息超出其在任何特定时刻可以处理的消息量,RabbitMQ 实施了一种名为信用流的内部机制,RabbitMQ 内部的各种系统将使用该机制来限制发布者,同时允许消息消费者赶上进度。在这篇博文中,我们将了解信用流的工作原理,以及我们可以做些什么来调整其配置以获得最佳行为。
RabbitMQ 3.3 的目标之一是您应该能够更轻松地找到运行系统中的瓶颈。旧版本的 RabbitMQ 可以让您看到您受到了速率限制,但不容易让您看到原因。在这篇博文中,我们将讨论版本 3.3 中的一些新的性能指标。
在开始之前我警告您:这是另一篇关于 RabbitMQ 3.3 中与性能相关的更改的冗长博文。还在看吗?很好。
所以在之前的帖子中,我提到了“我将在以后的博文中谈到的新功能”。该功能是消费者偏差。
好吧,我们昨天已经解决了坏消息,所以今天让我们来谈谈(一些)好消息:某些类型的发布和消费现在快得多,尤其是在集群中。
欢迎回来!上次我们讨论了流量控制和延迟;今天让我们讨论一下不同的功能如何影响我们看到的性能。这里有一些简单的场景。和以前一样,它们都是一个发布者和一个消费者尽可能快地发布的变体。
所以今天我想谈谈 RabbitMQ 性能的某些方面。有大量的变量会影响您可以从 RabbitMQ 服务器获得的整体性能水平,今天我们将尝试调整其中一些变量,看看我们可以看到什么。