RabbitMQ 3.13.0 现已发布！
RabbitMQ 3.13 现已发布，支持 MQTTv5、流过滤以及经典队列性能的显著改进，尤其是在处理较大消息时。
阅读专门的博文了解这些变化的更多详情
RabbitMQ 3.13 是 3.x 系列的最后一个次要版本。下一个版本将是 4.0！
Khepri（Mnesia 替换）的实验性支持
除了第一段中提到的新功能外，RabbitMQ 3.13 还增加了对 Khepri 的实验性支持。Khepri 是 RabbitMQ 元数据的新存储后端，旨在替换 Mnesia。它尚未准备好投入生产使用，但我们鼓励用户在测试环境中进行尝试并提供反馈。
我们的计划是在未来完全移除 Mnesia。这应该会显著提高 RabbitMQ 对网络分区故障的容忍度。一旦切换到 Khepri，将不再有分区处理策略配置（pause_minority、autoheal 等）— Khepri 基于 Raft 协议，就像仲裁队列一样，因此当发生分区时如何处理的语义是明确的且不可配置的。
关于 Khepri 的录制演讲已发布。
下面的命令启用了一个无法禁用的实验性功能。除非经过彻底测试，否则请勿在生产环境中使用它！
要启用 Khepri（3.13 版本实验性功能，且不可逆！），请运行
rabbitmqctl enable_feature_flag khepri_db
启用 Khepri 后，您应该不会注意到任何明显差异。主要区别在于声明交换器、队列、绑定等时的内部处理方式。我们鼓励进行实验，例如先声明您的实际拓扑，然后启用 Khepri（以验证一切是否按预期工作），模拟故障以验证集群是否仍然可用（只要多数节点正常运行且连接），等等。请报告您遇到的任何问题。
功能标志
RabbitMQ 3.13.0 包含了一些新的 功能标志。但是，它不会将任何旧的标志设置为必需（当然，除了那些在 3.12 版本中已经必需的）。因此，如果您禁用了一些功能标志，从 3.12 升级到 3.13 仍然可以工作。在 3.11 -> 3.12 升级中，如果不是所有功能标志都已启用，一些用户遇到了问题。从 3.12 迁移到 3.13 时不会出现此类问题。
在成功升级后，您应该始终启用所有非实验性功能标志。
经典队列：v1 版本仍是默认值
我们原本打算在 3.13 版本中将经典队列的默认版本更改为 v2，但最终决定不这样做。因此，v1 仍然是默认值，v2 仍然是一个可选功能。但是，强烈推荐使用经典队列 v2！您可以通过在策略中设置 x-queue-version=2 来升级您的队列。要确保新队列默认创建为 v2，您可以设置
classic_queue.default_version = 2
在 rabbitmq.conf 文件中。
v1 仍然是默认值的原因与 v2 的任何缺点无关，而是因为在某些场景下更改节点默认值会导致 v1 和 v2 之间进行反复迁移。特别是，在滚动升级期间，一个镜像队列会在 v1 和 v2 之间来回升级和降级，因为不同节点上的默认值会不同。为了避免此类情况的风险，我们决定不进行此更改。
未来，经典队列 v2 将成为唯一选项。届时，队列镜像功能将被移除，因此不会有与镜像相关的风险。
消息容器
消息容器 是一个在内部消息处理方式上几乎不可见的更改。RabbitMQ 最初是作为一个 AMQP 0-9-1 代理构建的。然而，多年来，它增加了对 AMQP 1.0、MQTT、STOMP 和 Streams 的支持。这导致了一些内部消息格式的转换，因为不同的协议具有大部分相似的概念，但在可用数据类型等细节上有所不同。
消息容器基于 AMQP 1.0 的消息格式，并考虑到当今多协议的假设，现代化了内部消息表示，并使协议之间的所有转换都变得显式。
这些转换现在已 记录。
3.x 系列到此结束！
RabbitMQ 3.0.0 于 2012 年 11 月发布。由于各种历史原因，主版本号自那时以来一直未增加。然而，现在是时候告别 3.x 系列，并在今年晚些时候转向 4.0 版本了。4.0 版本将包含一些破坏性更改，但最重要的是，它将不再支持经典队列的镜像。与镜像相关的策略键将被忽略，队列将成为单节点队列。这是对需要高可用性队列用户的最后呼吁：请尽快迁移到仲裁队列或 Streams（如果适用）。您将享受到比镜像队列更高的安全性、可靠性和更好的性能。