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 时，不会发生此类问题。
成功升级后，您应始终启用所有非实验性特性标志。
经典队列：版本 1 仍然是默认设置
我们原计划在 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 版本将包含许多重大更改，但最重要的是，它将不再支持经典队列的镜像。 与镜像相关的策略键将被忽略，队列将变为单节点队列。 这是对需要高可用队列的用户的最后呼吁：尽快迁移到仲裁队列，或在适用时迁移到流。 您将享受到比镜像队列提供的更高的数据安全性、可靠性和更好的性能。