java同步调用rabbitmq,使用RabbitMQ可以放慢同步发布/消耗速度

我正在评估RabbitMQ，虽然(AMQP本身，以及RabbitMQ)的总体印象是积极的，但我对结果并不是很满意 .

我正在尝试同时发布和使用消息，并且已经实现了非常差的消息速率 . 我有一个持久的直接交换，它绑定到一个持久的队列，我向该交换发布持久性消息 . 消息正文的平均大小约为1000字节 .

我的发布大致如下：

AMQP.BasicProperties.Builder bldr = new AMQP.BasicProperties.Builder();

ConnectionFactory factory = new ConnectionFactory();

factory.setUsername("guest");

factory.setPassword("guest");

factory.setVirtualHost("/");

factory.setHost("my-host");

factory.setPort(5672);

Connection conn = null;

Channel channel = null;

ObjectMapper mapper = new ObjectMapper(); //com.fasterxml.jackson.databind.ObjectMapper

try {

conn = factory.newConnection();

channel = conn.createChannel();

channel.confirmSelect();

} catch (IOException e) {}

for(Message m : messageList) { //the size of messageList happens to be 9945

try {

channel.basicPublish("exchange", "", bldr.deliveryMode(2).contentType("application/json").build(), mapper.writeValueAsBytes(cm));

} catch (Exception e) {}

}

try {

channel.waitForConfirms();

channel.close();

conn.close();

} catch (Exception e1) {}

并且从绑定队列中消费消息的方式如下：

AMQP.BasicProperties.Builder bldr = new AMQP.BasicProperties.Builder();

ConnectionFactory factory = new ConnectionFactory();

factory.setUsername("guest");

factory.setPassword("guest");

factory.setVirtualHost("/");

factory.setHost("my-host");

factory.setPort(5672);

Connection conn = null;

Channel channel = null;

try {

conn = factory.newConnection();

channel = conn.createChannel();

channel.basicQos(100);

while (true) {

GetResponse r = channel.basicGet("rawDataQueue", false);

if(r!=null)

channel.basicAck(r.getEnvelope().getDeliveryTag(), false);

}

} catch (IOException e) {}

问题是，当消息发布者(或其中几个)和消费者(或其中几个)同时运行时，发布者似乎全速运行，而RabbitMQ管理Web界面显示的发布率为，例如，每秒~2 ... 3K消息，但每个消费者的消耗率为0.5 ... 3 . 当出版商完成后，我得到的消费率为每个消费者300到600条消息 . 如果没有为Java客户端设置QOS预取值，那么稍微少一点，当设置为100或250时，则更多一点 .

在尝试对消费者进行一定程度的限制时，我已经成功地实现了同时发布的数据，例如每周发布约400条消息和消耗约50条消息，这些消息略微好一点，但只是略有增加 .

Here's，来自RabbitMQ博客条目的一句话，声称队列在空闲时很快就可以，但是当队列中有几千条持久性消息时，消耗速度降低到爬行速度仍然是相当不可接受的 .

较高的QOS预取值可能有所帮助，但恕我直言不是这样的解决方案 .

如果有的话，可以做些什么来实现合理的吞吐率(每个消费者每秒消耗2条消息在任何情况下都不合理)？这只是一个简单的直接交换 - 一个绑定 - 一个队列情况，我应该期望更复杂的配置会导致性能下降吗？在互联网上搜索时，也有建议放弃耐久性，但我担心在我的情况下这不是一个选择 . 如果有人会指出我是愚蠢的，并且有某种明显和直接的解决方案，我会很高兴:)