我们正在将 Artemis 从 VM 迁移到 K8s。作为代理本身弹性的证明，基于虚拟机的代理很少发生异常终止。通常，它会在我们整个 3 个月的发布周期中持续运行。
在 K8s 中，我们有一个由 3 个集群式仅实时 Artemis 代理 Pod 组成的 StatefulSet，每个 Pod 都有自己的持久卷。 PV 涵盖了（极不可能的）代理崩溃，并在重新启动时传递消息。不会产生关机延迟，仅会启动。在 K8s 中，由于 K8s 移动 Pod 进行资源重新分配、可能每月进行 K8s 补丁/Pod 基础映像操作系统升级或更改 Broker 配置设置，因此可能会出现滚动重启（代理正常关闭）。 Pod 缩小也是代理正常关闭。 Artemis 代理不知道滚动重启或 pod 缩减触发的 K8s 正常关闭之间有任何区别。
我们正在通过启用 Artemis 缩减 来寻求最短的消息传递延迟。通过将正常关闭代理的消息重新分发到另一个活动代理，可以避免 Pod 重新启动延迟。优雅的 Artemis Pod 重新启动（关闭 + 启动）以达到“AMQ221007：服务器现已上线”可能需要一分钟多的时间。
但是，我们遇到了一个开放的 Artemis 缩减错误：使用 Broker 集群连接使用的相同发现组时缩减失败。它描述了一个可能的解决方法
缩减使用的 JGroups 通道可能与代理使用的通道相同，但在代理关闭期间已被关闭。
作为解决方法，可以创建一个单独的发现组（具有自己的广播组），以便缩小规模使用不被代理关闭的新 JGroups 通道。但是，这会导致配置重复，并且必须打开用于缩小发现的新 JGroups 端口。
在那张票证中，我询问示例解决方法文件是否存在，因为我的尝试（包含在评论中）不成功。在这里要求更多的可见性和更广泛的群体，而不是埋在错误评论中。解决方法可行吗？
附加信息
我们无法解决这些问题，因此我们转向 ArtemisCloud，并成功将其部署到生产环境中。它有自己的一系列问题，主要是因为它适合我们现有的基础设施