如果ActiveMQ Artemis集群在Kubernetes环境中运行，则备份节点运行是否需要ON_DEMAND负载平衡？

问题描述

Kubernetes配置

• 活动节点的Kuberenetes StatefulSet（replicas = 2）：

  live-node1（与HA的backup-node1配对）

  live-node2（与HA的backup-node2配对）

• 活动节点的Kubernetes服务：

  live-node

• Kuberenetes StatefulSet（replicas = 2）用于备份节点：

  backup-node1

  backup-node2

• 备份节点的Kubernetes服务：

  backup-node

注意：客户端（发布者/消费者）始终通过K8s服务-live-node

连接到集群。

---

场景

• client1已连接到live-node1
• live-node1消失
• backup-node1接管
• client1将尝试通过K8s服务重新连接-live-node
• 它要么连接回live-node1（如果已备份），要么最终连接到live-node2
• 在后一种情况下，现有消息和新消息将如何使用和发布？

我的理解

• live-node1的所有客户端都将连接到live-node2
• 现有消息将重新分发给live-node2，因为backup-node1上没有消费者
• 新消息将通过live-node2发送和使用

请详细说明这种行为，如果我错了，请纠正我。

解决方法

严格来说，message-load-balancing上配置的cluster-connection类型与备份的工作方式完全无关。顾名思义，message-load-balancing类型与如何在群集中负载均衡消息有关。备份的行为取决于您配置的ha-policy。

进行备份的全部要点是，当活动节点发生故障时，所有连接到活动节点的客户端都将故障转移到备份节点。此外，备份节点将具有与活动节点相同的所有消息（通过复制或共享存储）。因此，您误以为当live-node1失败时，所有连接到live-node2的客户端都将连接到live-node1的想法。

也就是说，如果客户端确实确实连接到live-node2而不是backup-node1，则message-load-balancing类型必须为ON_DEMAND所需的消息最终从backup-node1重新分配到live-node2。显然，redistribution-delay也需要大于0。