版本：4.2

Khepri 已知问题

本文档列出了 Khepri 中可能影响集群技术运维的最常见已知问题。

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

注意

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

批量删除性能较低

目前，Khepri 删除大量实体（如队列、绑定或用户权限）的速度可能要慢得多。这是因为 Khepri 的集成试图与 Mnesia 的行为完全一致。因此，一些代码路径目前可能被大大优化，但由于 Mnesia 在 4.0.x 中仍然受支持，所以它们尚未得到优化。

RabbitMQ 维护者计划缩小与 Mnesia 在批量删除效率上的差距。他们似乎仅限于具有显著拓扑频繁变动的特定用例。

当 RabbitMQ 能够专门针对 Khepri 进行优化，即不再支持 Mnesia 时，这种差异将从根本上得到解决。从那时起，Khepri 在大多数工作负载下的性能将达到或超过早期版本中 Mnesia 的性能。

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

因此，RabbitMQ 代码并未习惯于从元数据存储中预期错误或超时。

使用 Khepri 时，如果尝试执行写操作（插入、更新、删除）的节点无法达成共识，则操作可能会超时。RabbitMQ 的大部分代码已进行了调整，以考虑这一新情况，但可能还有更多需要调整的领域，这些领域将在后续工作中发现并解决。

在此期间，RabbitMQ 节点上的某些 Erlang 进程可能会遇到超时异常。

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

客户端应用程序将收到一个错误，表明它可以稍后重试。

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

可以重新在它们上启用 Khepri。有一些启发式方法可以尝试让它们重新加入集群，但此时并不保证成功。