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

不公平分发

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

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

两个消费者都设置一下

 

 来看一下结果:

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

预取值

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

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

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

代码测试

 

 当测试生产者发送

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

 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

那山川

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值