ActiveMQ prefetchPolicy设1致消息超时，设0正常，是否误解概念？

关于prefetch=1的误解 #

你之前配置jms.prefetchPolicy.all=1时，误解了官方文档里“确保消费者一次仅处理一条消息”的表述。实际上，prefetch=1的逻辑是：消费者会预先从Broker获取1条消息缓存到本地，即使当前正在处理一条消息，这条预取的消息已经被分配给该消费者了。

在你的场景中，存在大量分钟级耗时的慢消息，当消费者拿到慢消息开始处理时，本地缓存的那条预取消息就会一直占用着消费者的“配额”，但消费者根本没时间处理它。这条预取的消息会一直处于“已分配但未处理”的状态，直到TTL过期被丢弃——这就是你之前遇到消息丢失的核心原因。

为什么prefetch=0能解决问题 #

当prefetch=0时，消费者不会预先获取消息，而是处理完当前消息后，主动向Broker发起轮询请求下一条消息。这种机制完全符合你“仅当消费者真正可用时才分配消息”的需求：只有当消费者彻底空闲，才会去Broker拿新消息，不会出现消息被分配给忙碌消费者后闲置超时的情况。

轮询真的是坏事吗？ #

官方文档说“推送优于轮询”是有前提的——针对高消息量、单消息处理耗时极短的场景，推送能减少消费者和Broker之间的网络交互次数，提升吞吐量。但你的场景是快慢消息混合，慢消息处理耗时长达分钟级，这时候轮询反而更合理：

• 只有消费者自己最清楚什么时候处理完消息，Broker主动推送很容易把消息分配给正在处理慢消息的消费者，导致消息闲置过期；
• 轮询带来的少量网络开销，和避免消息丢失、提升可靠性的收益相比，完全可以接受。

是否需要拆分快慢队列？ #

如果prefetch=0已经稳定解决了消息丢失问题，完全不需要立刻做架构拆分。只有当后续短耗时消息的吞吐量因为轮询受到明显影响时，再考虑拆分队列：

• 给快消息队列设置较大的预取值（比如1000），保留推送机制的性能优势；
• 给慢消息队列设置prefetch=0，确保消息仅分配给空闲消费者。

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