Redisson RStreams未ACK消息无法再次接收的解决方法咨询

StreamReadGroupArgs.neverDelivered() 底层对应Redis Stream消费组的 > 特殊ID标识，这个标识的原生语义就是仅拉取从未被分配给当前消费组内任何消费者的全新消息，已经被投递过但未执行ACK的消息会被记录在消费组的待处理列表（PEL）中，不属于全新消息范畴，自然不会被该参数的查询命中，这是Redis的原生设计，不是Redisson的功能异常。

• 新增PEL巡检前置逻辑
  每次调用readGroup拉取新消息前，优先查询并处理当前消费组下归属当前消费者的待处理消息。如果存在多消费者的场景，还可以额外判断待处理消息的空闲时长，把超过阈值（可根据业务平均处理时长自定义，比如30秒）的、归属于已离线消费者的消息，通过转移命令划归到当前消费者名下处理，避免节点宕机、网络波动导致的消息积压。
  Redisson 核心操作示例：

  RStream<String, Object> stream = redissonClient.getStream("your_stream_key");
  // 1. 转移空闲超过30秒的未确认消息到当前消费者
  List<StreamMessage<String, Object>> unackedMessages = stream.claim(
      "your_group_name", 
      "your_consumer_name", 
      Duration.ofSeconds(30), 
      StreamMessageId.ALL
  );
  // 2. 先处理转移过来的未确认消息，处理完成后调用ack
  for (StreamMessage<String, Object> msg : unackedMessages) {
      // 业务处理逻辑
      stream.ack("your_group_name", msg.getId());
  }
  // 3. 再拉取全新消息处理
  List<StreamMessage<String, Object>> newMessages = stream.readGroup(
      "your_group_name", 
      "your_consumer_name", 
      StreamReadGroupArgs.neverDelivered().count(10)
  );
  

• 引入死信队列兜底
  对于多次处理仍然失败的消息，不要无限重试，可标记后写入独立的死信Stream，定期人工排查处理，避免异常消息阻塞整个消费流程。
• 调整ACK时机
  不要在消息刚被拉取到的时候就执行ACK，要等业务逻辑完全处理完成、数据落库/操作生效后再返回ACK，避免业务处理失败但消息已被标记为已确认的情况。

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