小编Ero*_*ini的帖子

在我们的一个项目中，当我们使用具有大量消息（1M 或更多）的调度工具（在 ActiveMQ 配置中启用 schedulerSupport）时，我们正遭受 ActiveMQ 性能下降的困扰。该项目基于 Spring，我们也使用 Camel 进行路由管理。

我们的路由配置如下：

• 生产者 P 每秒产生 800 条消息，并通过非持久性 ActiveMQ 队列 Q 发送它们
• 消费者 Cq 根据以下规则处理来自 Q 的消息：对于每条消息，它验证消息是否可以立即处理（每条消息都有一个时间窗口属性来定义）。如果可能，Cq 将消息转发到 Throttling 队列 T；如果不是，Cq 将消息转发到支持队列 S
• 消费者 Cs 处理来自 S 的消息，并根据其时间窗口调度消息（ScheduledMessage.AMQ_SCHEDULED_DELAY使用以下语句设置 ActiveMQ 属性：）message.setLongProperty(ScheduledMessage.AMQ_SCHEDULED_DELAY, <delay>);其中<delay>根据消息时间窗口进行评估
• 当一个调度消息从 ActiveMQ 调度区唤醒时，它被转发到 Throttling 队列 T
• 消费者 Ct 使用第三方组件（通过 TCP 连接）处理来自 T 的消息

当 P 生成用于立即处理的消息（即，没有时间窗口）时，即使有大量消息（1M 或更多），系统也能很好地执行：监控队列我们可以看到它们几乎是空的（没有消息在任何队列中保持挂起） .

当 P 为延迟处理（即，使用时间窗口）生成消息时，我们会看到以下行为：

• 我们在所有队列（Q 和 S）中都有待处理的消息，而我们希望它们只在队列 S 上待处理
• 当 S 中调度的消息唤醒时，它们移动到 T 队列：这些消息根据节流配置（1K 消息/秒）进行处理
• 在 Q 和 …