4 篇带有“技术深度解析”标签的文章

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

RabbitMQ 3.12 中发布的原生 MQTT 为 IoT 用例带来了显著的可伸缩性和性能改进。

RabbitMQ 3.13 将支持MQTT 5.0，因此将是我们成为领先 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 中发布。

团队最近被问到，鉴于仲裁队列在可能的情况下会从本地队列副本（leader 或 follower）交付消息，它们是否以及如何提供与经典队列相同的消息排序保证。镜像队列始终从主节点（leader）交付，因此从任何队列副本交付听起来都可能影响这些保证。

这正是本帖的主题。请注意，本帖是一篇面向好奇者和分布式系统爱好者的技术深度分析。我们将探讨仲裁队列如何在不增加額外协调（Raft 之外）的情况下，从任何队列副本（leader 或 follower）交付消息，同时保持消息排序保证。