4 篇带有 “技术深入分析” 标签的帖子

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

Native MQTT released in RabbitMQ 3.12 has delivered substantial scalability and performance improvements for IoT use cases.

RabbitMQ 3.13 will support MQTT 5.0，这将是我们使 RabbitMQ 成为领先的 MQTT 代理之一的旅程中的下一个重要步骤。

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

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

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

结果非常惊人

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

Native MQTT 将 RabbitMQ 转变为 MQTT 代理，为更广泛的物联网用例打开了大门。

Native MQTT 在 RabbitMQ 3.12 中发布。

最近有人问到，仲裁队列在可能的情况下会从本地队列副本（leader 或 follower）传递消息，那么它们是否以及如何提供与经典队列相同的消息排序保证。镜像队列始终从 master（leader）传递消息，因此从任何队列副本传递消息听起来可能会影响这些保证。

这就是本文的主题。请注意，这篇文章是为好奇者和分布式系统爱好者准备的技术深入分析。我们将探讨仲裁队列如何在不额外协调（Raft 之外）的情况下，从任何队列副本（leader 或 follower）传递消息，同时保持消息排序保证。