多实例WebSocket消费SQS队列时能否跳过不匹配消息保留在队列

你设想的工作流无法基于原生SQS直接实现，以下是具体原理说明和可行方案参考：

SQS核心消费机制说明 #

首先回答你提到的疑问：SQS没有「只读不取出、保留在队列供其他消费者读取」的能力，它的消费逻辑是固定的：

• 消费者调用ReceiveMessage接口拉取消息后，消息不会立刻从队列删除，而是进入可见性超时窗口，这段时间内其他消费者无法拉取到该消息
• 消费者处理完成后调用DeleteMessage接口，消息才会被永久删除
• 若可见性超时后消费者未调用删除接口，消息会重新变回可见状态，可被其他消费者拉取

你设想的「三个消费者都能收到同一条消息」的需求，本质是广播消费模型，而SQS是典型的队列模型，单条消息默认只会被一个消费者成功消费，无法直接实现广播效果。

可行实现方案 #

方案1：SNS + 多SQS队列扇出（推荐） #

这是AWS生态下适配你场景的最优方案：

1. 新增一个SNS主题，生产者原本发往SQS的{"user_id": 1, "message": "Ciao"}格式消息改为发送到该SNS主题
2. 给每个WebSocket实例各创建一个专属的SQS队列，将三个队列都订阅到上述SNS主题
3. 每条消息发到SNS后会自动复制三份，分别推送到三个实例的专属队列
4. 每个实例只消费自己专属队列的消息：
   • 拉取到消息后判断是否持有对应用户的连接，持有则处理消息，之后调用删除接口删掉队列里的消息
   • 不持有则直接调用删除接口即可，其他实例的专属队列里仍有该消息副本，不影响其他实例处理

该方案完全符合你的业务需求，没有额外的无效开销，稳定性高。

方案2：单SQS队列适配（不推荐） #

如果不想引入SNS，也可以强行用单SQS队列模拟你的需求，逻辑如下：

• 所有实例共用同一个SQS队列，拉取到消息后先判断是否持有对应用户连接
• 若不持有，直接不做任何操作，等待可见性超时后消息重新回到队列，供其他实例拉取
• 若持有，处理完成后调用删除接口删掉消息

该方案存在三个明显缺陷：

• 消息处理延迟高，需要等待多次不可见超时后才会被正确的消费者拉取到
• 你需要调高SQS的「最大接收次数」阈值，否则消息被多次拉取未删除后会进入死信队列被丢弃
• 会产生大量无效的拉取、判断请求，增加成本和队列压力

内容的提问来源于stack exchange，提问作者Fabio B.