AWS SQS FIFO同MessageGroupId消息被多监听器接收问题求助

• 确认FIFO队列的核心配置有效性
  首先核实队列是否为标准FIFO类型：队列名称必须以.fifo结尾，且创建时指定了FifoQueue=true。非FIFO队列不具备同MessageGroupId消息的单节点独占消费特性，这是问题的核心前提。同时确保未手动禁用消息分组的默认约束，SQS FIFO默认会将同组消息分配给同一个消费者节点，直到该节点完成消息处理并确认删除。

• 修正消息确认与可见性超时配置
  检查消费者的消息确认逻辑：必须在Hibernate事务提交成功后，再调用DeleteMessage确认消息处理完成。若在事务提交前确认，一旦事务回滚会导致数据不一致；若未及时确认，消息会在可见性超时到期后重新进入队列，被其他节点接收。根据业务处理时长合理设置可见性超时，比如处理耗时5分钟则设为10分钟，避免消息提前重新分发。

• 排查消费者客户端的配置错误
  检查AWS SQS客户端（如Java SDK v2）的配置：

  • 确保客户端正确识别队列的FIFO属性，未错误使用标准队列的消费配置；
  • 若开启批量接收（maxNumberOfMessages），需保证同MessageGroupId的消息在同一个线程内顺序处理，禁止并行处理同组消息；
  • 检查客户端线程池配置，避免因线程复用导致同组消息被不同线程跨节点处理的异常情况。

• 添加业务层幂等性保障
  即使队列配置正确，极端场景下仍可能出现重复消费，需在业务层添加防护：

  • 利用SQS消息的MessageDeduplicationId作为唯一标识，在业务表中添加该字段的唯一约束，处理前先查询是否已存在该消息的处理记录；
  • 给Hibernate实体添加乐观锁字段（如version），当多个节点同时更新同一条数据时，仅第一个提交的事务会成功，其余事务会抛出乐观锁异常，此时可捕获异常并跳过处理或重试。

• 验证集群监听器的正确性
  确认两个节点的监听器均正确连接目标FIFO队列，无权限配置错误导致的状态异常。若使用Spring Cloud AWS等框架，检查监听器配置是否明确指定为FIFO队列类型，避免框架将其识别为标准队列而绕过分组机制。

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