集群环境下基于消息队列的长轮询通信问题咨询

问题背景 #

系统A负责用户账号注册，系统B为集群部署架构：

• 用户在B端提交注册信息后，发起长轮询请求等待注册结果
• B将注册信息发送至消息队列，A消费后完成账号创建，再向另一队列发送注册完成消息
• B消费注册完成消息时需通知用户，但集群中处理该消息的实例，无法保证与持有用户长轮询请求的实例为同一台

现有方案及弊端分析 #

1. JGroups集群广播 #

• 弊端：所有集群实例都会收到消息，带来额外的带宽和计算负载，集群规模越大开销越显著；且大部分实例无需处理该消息，属于无效分发，资源浪费严重。

2. SNS扇出至每个实例专属SQS队列 #

• 弊端：队列数量随实例数线性增长，增加运维复杂度；消息会被所有实例重复处理，资源利用率低；实例动态扩缩容时，队列的创建/销毁需要额外管控逻辑，易出现漏处理或资源残留问题。

3. 追踪请求所在服务器并路由消息 #

• 弊端：长轮询超时后用户发起新请求，请求可能落在其他实例，原有路由信息失效；若实例宕机，路由的消息会丢失或无法处理；需额外维护请求与实例的映射状态，增加系统复杂度。

4. 改用标准轮询消除状态依赖 #

• 弊端：客户端频繁发起请求，增加网络和服务端负载；用户等待体验差于长轮询；轮询间隔难以平衡，间隔太短负载过高，太长则通知延迟大。

优化方案建议 #

方案一：引入分布式状态存储，解耦实例与请求绑定 #

核心思路：将用户长轮询的关联状态存储到Redis等分布式存储中，让集群任意实例都能处理注册完成消息并定位用户请求。

• 流程：
  1. 用户提交注册后，B生成唯一注册请求ID，将用户ID、请求ID、长轮询超时时间等信息存入Redis
  2. B向队列发送注册请求消息，携带注册请求ID
  3. A完成注册后，发送携带请求ID和结果的完成消息到队列
  4. 任意B实例消费消息后，通过请求ID从Redis查询长轮询状态：
     • 若长轮询未超时，直接通过长轮询连接推送结果
     • 若长轮询已超时，将结果存入Redis，等待用户后续请求查询
• 优势：无需绑定特定实例，集群扩展性强；状态集中存储，避免实例宕机导致状态丢失；天然支持长轮询超时后的重试场景。

方案二：WebSocket替代长轮询，配合分布式推送 #

核心思路：用WebSocket双向通信替代长轮询，将连接信息存入分布式存储，实现跨实例的精准推送。

• 流程：
  1. 用户提交注册后，B与用户建立WebSocket连接，将连接ID、用户ID、注册请求ID关联存入Redis
  2. B向队列发送注册请求消息
  3. A完成注册后，发送携带请求ID和结果的完成消息
  4. 任意B实例消费消息后，通过请求ID从Redis获取对应连接ID，再借助Redis Pub/Sub等机制，将结果推送给目标WebSocket连接
• 优势：通知更及时，无需长轮询的超时重试逻辑；分布式存储连接信息，集群任意节点都能处理推送。

方案三：优化路由方案，补充状态过期与重试机制 #

针对方案3的缺陷做针对性改进：

• 在分布式存储中为请求-实例映射设置略长于长轮询超时时间的过期时间
• 当B实例消费消息后查询映射失效时，将消息存入延迟队列，等待一段时间后重新处理；用户发起新长轮询时，更新映射信息
• 增加消息重试次数，若多次重试仍无法找到对应实例，将结果存入用户状态存储，等待用户主动查询
• 优势：保留精准路由的低负载优势，同时解决超时和实例宕机的边缘场景

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