java 操作 rabbitmq, basicQos失效问题

Posted 2023-04-27

请教一下，消费者，代码里 设置了 basicQos(5),但获得消息时，仍然是一个一个的获得的还是轮询的，不应该是一下得到5个么，只有 basicQos(1)时，才有效。请教一下怎么解决

参考技术A 这个应该放在消费者那边，你写错了位置。并且这个不是限定每次消费的个数，而是限定消费者不进行确认消息消费成功的次数。就是出现多少次消费不成功就不像该消费者发送消息了 参考技术B 解决办法：
是<rabbit:listener-container prefetch="1" >的属性设置

RabbitMQ-08 不公平分发与预取值

不公平分发

        我们之前演示的所有示例都遵循轮询分发，也就是多个消费者时交替消费队列消息。可以想一下我们之前的一个例子。Worker02处理消息只需要1s但是Worker03处理一个消息却用30s的情况。那么这个时候我们就要使用到不公平分发。简而言之就是能者多劳。

        需要在消费方设置channel.basicQos(1)；

两个消费者都设置一下

 

 来看一下结果：

 显而易见，Worker02处理消息速度快，所以处理了5条消息

预取值

        其实预取值与不公平分发原理是相同的，只不过当预取值为1的时候，channel里面最多只能存一个消息，所以可以体现出能者多劳。本身消息的发送就是异步发送的，所以在任何时候，channel上肯定不止只有一个消息另外来自消费者的手动确认本质上也是异步的。因此这里就存在一个未确认的消息缓冲区，因此希望开发人员能限制此缓冲区的大小，以避免缓冲区里面无限制的未确认消息问题。

        可以通过使用basicqos方法设置“预取计数”值来完成.该值定义通道上允许的未确认消息的最大数量。增加预取将提高向消费者传递消息的速度。虽然自动应答传输消息速率是最佳的，但是，在这种情况下已传递但尚未处理的消息的数量也会增加，从而增加了消费者的RAM消耗(随机存取存储器)应该小心使用具有无限预处理的自动确认模式或手动确认模式，

        不同的负载该值取值也不同100到300范围内的值通常可提供最佳的吞吐量，并且不会给消费者带来太大的风险。预取值为1是最保守的。当然这将使吞吐量变得很低，特别是消费者连接延迟很严重的情况下，特别是在消费者连接等待时间较长的环境中。对于大多数应用来说，稍微高一点的值将是最佳的。

代码测试

 

 当测试生产者发送

        简单概述就是先优先填充信道至自己设置的prefetchCount，后续消费快的继续消费。毕竟消费快自己的chanel里面的消息被ack的也快。