元数据存储
元数据存储的作用
元数据存储是一个数据库，RabbitMQ 在其中记录除队列和流消息之外的所有内容：
- 内部数据存储中的用户和权限；“内部”指相对于外部定义的用户（例如 LDAP）
- 虚拟主机 (Virtual hosts)
- 拓扑结构：交换机、队列、流、绑定
- 运行时参数
- 策略 (Policies)
在集群中，元数据存储负责将这些数据复制到所有 RabbitMQ 节点。
元数据存储子系统依赖于后端库来提供数据库、其复制算法以及故障恢复特性。
支持的后端
RabbitMQ 支持两种不同的元数据存储
- Khepri（较新，推荐）
- Mnesia（原始元数据存储）
在任何给定时间只能使用其中之一。下面将分别介绍它们。
Mnesia
Mnesia 是原始后端，也是 RabbitMQ 3.13.x 之前唯一使用的后端。该库是 Erlang/OTP 标准发行版的一部分。
它相当高效，提供事务和集群复制，具有备份和恢复 API，并且作为原生的 Erlang/OTP 库，能够完美集成到任何 Erlang 应用程序中。
Mnesia 的弱点在于其故障恢复特性，尤其是在网络分区方面。其复制算法假设使用 Mnesia 的系统可以承受丢弃网络分区一侧的所有数据，但这并不总是事实，也不符合许多技术运营团队的预期。
使用 Mnesia 时，如果两个节点在一段时间内无法通信且数据库在其中一侧被更新（例如声明了队列），则需要由 RabbitMQ 来解决数据冲突。
为了处理这个问题，RabbitMQ 引入了网络分区策略。然而，它们绝不是根本性的解决方案，而且难以进行逻辑推演。
Khepri
Khepri 是从 RabbitMQ 4.0.x 开始完全支持的元数据存储。它由 RabbitMQ 团队开发，并复用了大量为仲裁队列 (Quorum queues) 和流 (Streams) 所做的工作。
事实上，所有这些组件都基于 Raft 一致性算法。因此，在连接丢失的情况下，其行为定义明确，且更容易推演。由于它们都使用相同的算法，这种行为在 RabbitMQ 各个组件和子系统之间也是一致的。
其最终目标是完全切换到 Khepri，并停止使用 Mnesia。然而，与 Mnesia 相比，使用 Khepri 是一项破坏性的变更——即使它只是一个内部组件——因为它会影响在集群或网络出现故障时用户可见的各种行为。
如果您想了解更多关于 Khepri 及其集成到 RabbitMQ 的信息，该项目的开发人员 Michael Davis 在 Code BEAM Europe 2023 会议上做了一个演讲。您可以在 YouTube 上观看 “Khepri: Replacing Mnesia in RabbitMQ” 的录像。
从 RabbitMQ 4.2.0 开始，Khepri 成为默认后端。
Mnesia 仍将得到支持。现有的 RabbitMQ 部署在升级到 RabbitMQ 4.2.x 后将继续使用它，直到管理员显式启用 Khepri。
Mnesia 的支持将在未来版本中移除。因此，RabbitMQ 团队鼓励用户使用 Khepri 测试他们的工作负载和应用程序，以使其真正成熟，成为 RabbitMQ 未来默认的（也是唯一的）元数据存储。
接下来的几页将解释如何启用 Khepri，并将涵盖针对各种日常操作的行为变化。