Khepri 的已知问题

本文档列出了 Khepri 最常见的已知问题，这些问题可能会影响集群的技术操作。

本指南的目标是让用户能够就他们是否可以在 RabbitMQ 4.0.x 中采用 Khepri 做出明智的决定。

注意

当我们谈论 Khepri 的已知问题时，我们实际上指的是两种不同的情况

• Khepri 库本身中的错误和限制
• RabbitMQ 中 Khepri 集成的错误和回归

批量删除的性能较低

目前，Khepri 在删除大量实体（如队列、绑定或用户权限）时可能会慢得多。这源于 Khepri 的集成试图与 Mnesia 行为保持一致。因此，某些代码路径可能可以为 Khepri 大大优化，但目前尚未优化，因为 4.0.x 中仍然支持 Mnesia。

RabbitMQ 维护人员计划缩小与 Mnesia 批量删除效率的差距。它们似乎仅限于拓扑结构发生显著变化的特定用例。

一旦 RabbitMQ 可以专门针对 Khepri 进行优化（即，当 Mnesia 支持被删除时），这种差异将从根本上得到解决。从那时起，Khepri 在大多数工作负载上的性能将与早期版本中的 Mnesia 相匹配或超过 Mnesia。

超时处理

在 Mnesia 中，事务可能会因超时而失败。因此，Mnesia 中的表可能会变得不一致，并且在网络或应用程序故障后可能会发生冲突，应用程序必须解决这些冲突。RabbitMQ 通过其网络分区恢复策略在一定程度上缓解了这些问题。

因此，RabbitMQ 代码过去不期望元数据存储返回错误或超时。

对于 Khepri，如果尝试执行写入（插入、更新、删除）的节点无法达成共识，则写入可能会超时。RabbitMQ 的大多数部分都已调整以考虑这一新情况，但可能还有更多领域需要调整，这些领域将在一段时间内被发现和解决。

同时，RabbitMQ 节点上的一些 Erlang 进程可能会遇到超时异常。

请注意，当发生此类超时时，由于 Raft 的复制和故障恢复特性，存储在 Khepri 中的数据很可能仍然是安全的。

客户端应用程序将收到一个错误，它可以在一段时间后重试。

在一个或多个节点数据永久丢失后恢复

如果一个或多个节点丢失了它们的数据，甚至整个磁盘，它们将无法重新加入集群。原因是它们丢失了特性标志状态以及集群成员状态。

可以在它们上面再次启用 Khepri。有一些启发式方法可以尝试将它们重新加入集群，但在这一点上，成功并不能得到保证。