Khepri 已知问题
本文档列出了 Khepri 最常见已知问题，这些问题可能会影响集群的技术操作。
本指南的目标是让用户能够对是否在 RabbitMQ 4.0.x 中采用 Khepri做出明智的决定。
当我们谈论 Khepri 的已知问题时，实际上是指两件不同的事情
- Khepri 库本身的错误和限制
- 在 RabbitMQ 中集成 Khepri 时发生的错误和回归
批量删除的性能较低
目前，Khepri 在删除大量实体（如队列、绑定或用户权限）时速度可能会慢很多。这是因为 Khepri 的集成试图与 Mnesia 的行为保持一致。因此，一些代码路径可以针对 Khepri 进行大幅优化，但目前还没有进行优化，因为 Mnesia 仍在 4.0.x 中得到支持。
RabbitMQ 维护人员计划缩小 Khepri 与 Mnesia 在批量删除效率方面的差距。这似乎仅限于拓扑结构发生重大变化的特定用例。
当 RabbitMQ 可以针对 Khepri 进行专门优化时，这种差异将从根本上得到解决，也就是说，当 Mnesia 支持被移除时。从那时起，Khepri 在大多数工作负载上的性能将匹配或超过早期版本中 Mnesia 的性能。
超时处理
在 Mnesia 中，事务可能会因超时而失败。因此，Mnesia 中的表可能会变得不一致，并且可能会发生应用程序需要在网络或应用程序故障后解决的冲突。RabbitMQ 通过其网络分区恢复策略在一定程度上缓解了这些问题。
因此，RabbitMQ 代码并不期望元数据存储出现错误或超时。
使用 Khepri 时，如果尝试执行写入操作（插入、更新、删除）的节点无法达成一致，则写入操作可能会超时。RabbitMQ 的大部分代码都进行了调整以考虑这一新情况，但可能仍有一些需要调整的区域，这些区域将在发现后得到解决。
在此期间，RabbitMQ 节点上的一些 Erlang 进程可能会遇到超时异常。
请注意，当出现此类超时情况时，由于 Raft 的复制和故障恢复特性，存储在 Khepri 中的数据很可能保持安全。
客户端应用程序将收到一个错误，它可以在一段时间后重试。
在一个或多个节点数据永久丢失后的恢复
如果一个或多个节点丢失其数据甚至整个磁盘，则它们将无法重新加入集群。原因是它们也丢失了其特性标志状态以及其集群成员资格状态。
可以在这些节点上再次启用 Khepri。有一些启发式方法可以尝试将它们重新加入集群，但目前无法保证成功。