ActiveMQ队列上的奇怪行为

我们在生产中使用AMQ已经有一段时间了，我们注意到一个队列中出现了一种奇怪的行为

情况如下：

• 我们使用clickstream流量，因此当我们识别出一个用户时，他的所有事件都会根据JMSXGroupID属性（在我们的例子中，这是一个UUID，我们每小时可以有数百万个）进行“分组”，因此我们有一定的顺序来使用同一用户的事件，以防它们发生突发
• 我们将KahaDB与以下配置一起使用：

  <mKahaDB directory="${activemq.data}/mkahadb">
  <filteredPersistenceAdapters>
      <filteredKahaDB perDestination="true">
          <persistenceAdapter>
              <kahaDB checkForCorruptJournalFiles="true" journalDiskSyncStrategy="PERIODIC" journalDiskSyncInterval="5000" preallocationStrategy="zeros" concurrentStoreAndDispatchQueues="false" />
          </persistenceAdapter>
      </filteredKahaDB>
  </filteredPersistenceAdapters>
  

• 代理处于一个相当强大的EC2实例中，但它似乎没有达到任何限制，既没有文件限制，也没有IOPS限制，也没有CPU限制

• 此目的地的目的地策略使用，非常类似于对JMSXGroupID使用相同分组的许多其他目的地：

  <policyEntry queue="suchDestination>" producerFlowControl="false" memoryLimit="256mb" maxPageSize="5000" maxBrowsePageSize="2000"> 
  <messageGroupMapFactory>
      <simpleMessageGroupMapFactory/>
  </messageGroupMapFactory>
  <deadLetterStrategy>
      <individualDeadLetterStrategy queuePrefix="DLQ." useQueueForQueueMessages="true" />
  </deadLetterStrategy>
  

• 与其他目的地相比，消费者使用消息的速度相当慢（与其他目的地相比，每条消息大约50-100ms） 其他目的地的其他用户（每条消息约10-30毫秒）

• 然而，似乎我们最终会遇到这样一种情况：消费者并没有以我们期望的速度消费，并且似乎在等待某件事情，而远程代理上有大量用于该目的地的消息。消费者似乎既不是CPU，也不是IO绑定，也不是网络流量绑定

• 一个症状是，如果我们将该队列拆分为两个队列，并在相同数量的节点中附加相同数量的使用者来使用它，那么情况会以某种方式变得更好。此外，如果该队列的工作负载很大，如果我们只是在生产者上将其重命名为suchQueue2，并在其上分配一些消费者，那么这些消费者比“旧”suchQueue上的消费者要快得多（暂时）

• 队列没有“非分组消息”，队列上的所有消息都具有JMSXGroupID属性，并且类型相同

• 增加或降低该队列的消费者数量似乎没有什么效果

• 一旦队列变得“消费缓慢”，重新启动消费者应用程序似乎没有什么效果

有没有人经历过这种情况：

简言之：

---

经纪人等待消费者的时间相当长，他们似乎一直都很空闲，并不忙碌。

我也遇到了同样的问题。你找到答案了吗？