1. 监听消息队列具体指的是什么？ #

简单来说，监听消息队列就是让你的应用程序持续保持对目标消息队列的关注状态——不用你主动去“询问”队列有没有新消息，当队列中出现待处理的新消息时，要么是队列主动把消息推送给监听的应用，要么是应用一直处于低功耗的等待状态，一旦检测到新消息就立刻触发处理逻辑。

举个实际例子：做电商系统时，用户支付成功后，支付结果会被发送到消息队列里。如果你的发货服务是“监听”这个队列的，那么新的支付成功消息一进来，发货服务会马上收到并启动发货流程，完全不用写代码每隔一段时间去查队列里有没有新消息。

2. Queue Listener 与每分钟拉取请求的差异 #

这两种方式的核心差异体现在触发时机、资源消耗和业务适配性上，具体对比如下：

• 实时性：
  Queue Listener是“实时响应”的，消息一抵达队列就会被处理，几乎没有延迟；而每分钟拉取的方式，最快也要等一分钟才能处理新消息，如果消息刚好在拉取后的一秒钟进来，就要等59秒才能被处理，延迟非常不稳定。
• 资源消耗：
  Queue Listener通常是长连接或轻量级等待状态，大部分时间只是维持监听，资源消耗极低；而定时拉取的方式，不管队列有没有消息，都要定时发起请求、建立连接、查询队列，频繁的无意义请求会浪费服务器的CPU和网络资源，尤其是队列空闲时，这种消耗完全没必要。
• 可靠性：
  正规的Queue Listener一般会和队列服务有心跳机制，连接断开后会自动重连，基本不会错过消息；而定时拉取的方式，如果某次拉取请求失败（比如网络波动），那这一分钟内的消息就可能被遗漏，除非额外做重试和消息追踪逻辑，复杂度会高很多。
• 适用场景：
  Queue Listener适合对实时性要求高的场景，比如订单处理、实时通知、日志分析；而每分钟拉取只适合对延迟完全不敏感、且消息量极小的场景，比如每天只有几条消息的内部统计任务。

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