STOMP客户端确认模式下ActiveMQ Artemis重复消息投递的解决方案咨询

首先咱们拆解下问题根源：你用了client ack模式，页面重载时每次生成新的订阅ID，ActiveMQ Artemis会把这个新订阅当成全新的消费者，而之前未被ack的消息（旧连接断开没来得及确认）就会被重发给新消费者，所以出现了redelivered: true的情况。要实现“可靠且仅投递一次”，得从订阅标识、ack时机、幂等处理这几个角度入手，下面是具体方案：

1. 固定订阅ID，避免随机生成 #

STOMP的订阅ID是消息代理识别消费者身份的核心标识。你现在每次调用generateId()生成新ID，相当于每次都是新消费者订阅队列，自然会触发重发。

修改方案：把订阅ID绑定到用户/会话的唯一标识上（比如你已经用到的rscSessionId），这样页面重载后用同一个ID订阅，Artemis会识别为同一个消费者的重新连接，而非新消费者。

修改后的订阅代码：

consumer.subscribe( '/queue.'+ rscSessionId, function (response) { 
  console.log("response"); 
}, { 
  "subscription-type": "ANYCAST", 
  ack: "client", 
  id: `sub-${rscSessionId}`, // 用rscSessionId固定订阅ID，保证页面重载后不变
} );

2. 页面卸载前主动ack已处理消息 #

页面重载/关闭时，旧连接会断开，如果还有已接收但未ack的消息，Artemis会认为这些消息未被处理，进而重发。咱们可以监听页面卸载事件，在断开前完成ack操作。

示例代码：

// 维护已接收但未ack的消息ID列表
let unackedMessageIds = [];

consumer.subscribe( '/queue.'+ rscSessionId, function (response) { 
  const msgId = response.headers['message-id'];
  unackedMessageIds.push(msgId);
  
  // 执行你的业务逻辑...
  
  // 处理完成后从列表移除并ack
  unackedMessageIds = unackedMessageIds.filter(id => id !== msgId);
  consumer.ack(msgId);
}, { 
  "subscription-type": "ANYCAST", 
  ack: "client", 
  id: `sub-${rscSessionId}`,
} );

// 监听页面卸载事件，ack剩余未处理的消息
window.addEventListener('beforeunload', () => {
  unackedMessageIds.forEach(msgId => {
    consumer.ack(msgId);
  });
});

⚠️ 注意：beforeunload的执行时间有限，要确保ack操作轻量快速，避免超时。

3. 客户端实现消息幂等处理 #

即使前面的措施都做了，也可能因为网络波动、页面崩溃等极端情况导致消息重发。这时候需要客户端自己做幂等处理——识别重复消息，避免重复执行业务逻辑。

核心思路是用消息头里的message-id作为唯一标识，把已处理的消息ID存在本地存储（比如localStorage），页面重载后恢复这个列表，收到消息时先检查是否已经处理过：

示例代码：

// 从localStorage恢复已处理的消息ID列表
let processedMsgIds = JSON.parse(localStorage.getItem('processedMsgIds')) || [];

consumer.subscribe( '/queue.'+ rscSessionId, function (response) { 
  const msgId = response.headers['message-id'];
  
  // 检查是否已处理过
  if (processedMsgIds.includes(msgId)) {
    // 直接ack，不执行业务逻辑
    consumer.ack(msgId);
    return;
  }
  
  // 执行你的业务逻辑...
  console.log("processing message:", response);
  
  // 标记为已处理，并存入localStorage
  processedMsgIds.push(msgId);
  localStorage.setItem('processedMsgIds', JSON.stringify(processedMsgIds));
  
  // 处理完成后ack
  consumer.ack(msgId);
}, { 
  "subscription-type": "ANYCAST", 
  ack: "client", 
  id: `sub-${rscSessionId}`,
} );

这样即使消息被重发（redelivered: true），客户端也会直接跳过重复处理，保证业务逻辑只执行一次。

4. 可选：结合持久订阅增强可靠性 #

如果你的业务需要更高的可靠性（比如客户端离线很久后重新连接，也要收到未处理的消息），可以开启STOMP的持久订阅：

在订阅参数里添加durable: true，同时确保客户端ID（__AMQ_CID）固定（可以在STOMP连接时设置clientId参数）：

// 连接STOMP时设置固定的clientId
const client = Stomp.client('ws://your-artemis-host:61614/ws');
client.connect({
  clientId: `user-${userId}`, // 用用户ID固定客户端ID
}, () => {
  // 订阅时开启持久化
  consumer.subscribe( '/queue.'+ rscSessionId, function (response) { 
    // ...业务逻辑
  }, { 
    "subscription-type": "ANYCAST", 
    ack: "client", 
    id: `sub-${rscSessionId}`,
    durable: true, // 开启持久订阅
  } );
});

持久订阅会让Artemis保存订阅状态，即使客户端离线，消息也会被保留，直到客户端重新连接并ack。

总结 #

把固定订阅ID、页面卸载前ack、客户端幂等处理这三个措施结合起来，就能在保证消息不丢失的前提下，实现“仅投递/处理一次”的效果。如果需要更强的离线可靠性，可以再加上持久订阅。

内容的提问来源于stack exchange，提问作者pacman