带“技术深入探讨”标签的 4 篇文章

这篇博文概述了 AMQP 1.0 流量控制相对于 AMQP 0.9.1 的十个优势，并通过两个基准测试证明了显著的性能提升。此外，我们深入探讨了强大的 AMQP 1.0 流量控制原语及其在 RabbitMQ 中的使用方式。

RabbitMQ 3.12 中发布的原生 MQTT为物联网用例带来了显著的可扩展性和性能提升。

RabbitMQ 3.13 将支持MQTT 5.0，因此将成为我们在将 RabbitMQ 打造成领先的 MQTT 代理的旅程中的下一个重要里程碑。

这篇博文解释了如何在 RabbitMQ 中使用新的 MQTT 5.0 功能。

RabbitMQ 的核心协议一直是 AMQP 0.9.1。为了支持 MQTT、STOMP 和 AMQP 1.0，代理通过其核心协议进行透明代理。虽然这是一种通过支持更多消息传递协议来扩展 RabbitMQ 的简单方法，但它会降低可扩展性和性能。

在过去的 9 个月里，我们重新编写了MQTT 插件，不再通过 AMQP 0.9.1 进行代理。相反，MQTT 插件解析 MQTT 消息并将其直接发送到队列。这就是我们所说的 **原生 MQTT**。

结果令人惊叹

1. 在许多连接情况下，内存使用量降低了 95% 和数百 GB。
2. RabbitMQ 首次能够处理数百万个连接。
3. 端到端延迟降低了 50% - 70%。
4. 吞吐量提高了 30% - 40%。

原生 MQTT 将 RabbitMQ 变成一个 MQTT 代理，为更广泛的物联网用例打开了大门。

原生 MQTT 在 RabbitMQ 3.12 中发布。

团队最近被问到仲裁队列是否以及如何能够提供与经典队列相同的消息排序保证，因为它们将在可能的情况下从本地队列副本（领导者或跟随者）中交付消息。镜像队列总是从主节点（领导者）中交付，因此从任何队列副本中交付听起来可能会影响这些保证。

这就是这篇文章的主题。请注意，这篇文章是为好奇和分布式系统爱好者准备的技术深入探讨。我们将探讨仲裁队列如何能够从任何队列副本（领导者或跟随者）中交付消息，而无需额外的协调（除了 Raft），同时保持消息排序保证。