Spring AMQP消息延迟

时间:2016-09-21 09:14:55

标签: spring-amqp

我的问题与此问题非常相似:Why is there a delay in Spring AMQP Message dispatching from a filled Queue?

即使队列中充满了消息,我也可以看到消息监听器的两次调用之间的延迟。我已经在方法的开头,结束时的时间以及采用该方法的时间(以毫秒为单位)中添加了一条日志消息:

开始 - 结束 - 时间
2016-09-21T10:08:55.263; - 2016-09-21T10:08:55.278; - 15;
2016-09-21T10:08:55.356; - 2016-09-21T10:08:55.356; - 0;
2016-09-21T10:08:55.388; - 2016-09-21T10:08:55.388; - 0;
2016-09-21T10:08:55.466; - 2016-09-21T10:08:55.466; - 0;

处理消息的时间大约是10毫秒(平均值),但我可以看到延迟时间大于50毫秒(有时候大于100毫秒)。

如果我将SimpleMessageListenerContainer的参数PrefetchCount更改为(例如200),那么性能会有所提高,现在我可以在日志中看到延迟已消失:

开始 - 结束 - 时间
2016-09-21T10:26:27.336; - 2016-09-21T10:26:27.336; - 0;
2016-09-21T10:26:27.336; - 2016-09-21T10:26:27.351; - 15;
2016-09-21T10:26:27.351; - 2016-09-21T10:26:27.351; - 0;
2016-09-21T10:26:27.351; - 2016-09-21T10:26:27.351; - 0;

我的问题是:

  • 这种延迟会带来什么?真的是网络延迟吗?我该如何证明这一点?
  • 我在文档中看到过“prefetchCount”:“越高,消息传递得越快,但非顺序处理的风险就越大。”这究竟意味着什么?如果我需要按顺序处理消息,我可以将“prefetchCount”更多地设置为tan 1吗?

我的配置是这样的:

    @Bean   
    public MessageListenerAdapter broadcastMessageListenerAdapter() {
       return new MessageListenerAdapter(myHandlerBroadcast(), "onMessage");
    }

@Bean(name="myBroadcastMessageListenerContainer") 
public SimpleMessageListenerContainer myBroadcastMessageListenerContainer() 
{
    SimpleMessageListenerContainer container = new SimpleMessageListenerContainer(myConnectionFactory());
    container.setQueueNames(PX_BROADCAST_QUEUE + environment.getProperty("my.user"));
    container.setMessageListener(broadcastMessageListenerAdapter());
    container.setAcknowledgeMode(AcknowledgeMode.AUTO);
    container.setMessageConverter(myMessageConverter());
    container.setConcurrentConsumers(1);
    container.setAutoStartup(false);
    container.setPrefetchCount(500);        // ¿1?
    return container;
 }

@Bean(name="myHandlerBroadcast")
public MyHandlerBroadcast myHandlerBroadcast(){
  return new MyHandlerBroadcast();
}

1 个答案:

答案 0 :(得分:2)

是;这是网络。您可以使用网络监视器“证明”它。默认情况下,prefetchCount为1,这意味着代理只允许消费者使用一条未确认的消息。只有当该消息被确认时才会发送下一个消息。

增加预取计数会显着提高性能,但会导致无序传送。

  

这究竟是什么意思?

考虑预取计数为10.您处理5条消息然后出现故障(#6)并且消息被拒绝并重新排队(如果已配置)。

当您使用了所有预取消息后,将重新传递消息#6 - 因此它将无序。

如果您从未对邮件进行重新排队,那么邮件传递顺序就没有问题。