[000-01-022].第09节:RabbitMQ中的消息分发策略

我的后端学习大纲
RabbitMQ学习大纲


1.不公平分发:

1.1.什么是不公平分发:

  • 1.在最开始的时候我们学习到 RabbitMQ 分发消息采用的轮训分发,但在某种场景下这种策略并不是很好,比方说有两个消费者在处理任务,其中有个消费者 1 处理任务的速度非常快,而另外一个消费者2处理速度却很慢,这个时候我们还是采用轮训分发的化就会到这处理速度快的这个消费者很大一部分时间处于空闲状态,而处理慢的那个消费者一直在干活,此时轮训分配方式在这种情况下就不好,但RabbitMQ 并不知道这种情况它依然很公平的进行分发。为避免这种情况,可以在消费者方设置参数 channel.basicQos(1)

1.2.编码实现不公平分发:

  • 1.在消费者方添加如下两行代码,实现消息的不公平分发:
  • 2.管理页面这里代表的是不公平分发:
  • 3.测试:

1.3.此种模式下可能存在的问题:

  • 如果这个任务我还没有处理完或者我还没有应答你,你先别分配给我,我目前只能处理一个任务,然后 rabbitmq 就会把该任务分配给没有那么忙的那个空闲消费者
  • 当然如果所有的消费者都没有完成手上任务,队列还在不停的添加新任务,队列有可能就会遇到队列被撑满的情况,这个时候就只能添加新的 worker 或者改变其他存储任务的策略。

2.预取值

2.1.什么是预期值:

  • 1.本身消息的发送就是异步发送的,所以在任何时候,channel 上肯定不止只有一个消息
  • 2.另外来自消费者的手动确认本质上也是异步的。因此这里就存在一个未确认的消息缓冲区,因此希望开发人员能限制此缓冲区的大小,以避免缓冲区里面无限制的未确认消息问题。这个时候就可以通过使用 basic.qos 方法设置"预取计数"值来完成的

2.2.管理页面上查看预取值:

  • 1.这里是管理页面上代表预取值的地方,默认是1:
  • 2.该值定义通道上允许的未确认消息的最大数量。一旦数量达到配置的数量,RabbitMQ 将停止在通道上传递更多消息,除非至少有一个未处理的消息被确认,例如,假设在通道上有未确认的消息 5、6、7,8,并且通道的预取计数设置为 4,此时 RabbitMQ 将不会在该通道上再传递任何消息,除非至少有一个未应答的消息被 ack。比方说 tag=6 这个消息刚刚被确认 ACK,RabbitMQ 将会感知这个情况到并再发送一条消息。消息应答和 QoS 预取值对用户吞吐量有重大影响。

2.3.预取值说明:

  • 1.通常,增加预取将提高向消费者传递消息的速度。虽然自动应答传输消息速率是最佳的,但是,在这种情况下已传递但尚未处理的消息的数量也会增加,从而增加了消费者的 RAM 消耗(随机存取存储器),所以应该小心使用具有无限预处理的自动确认模式或手动确认模式,消费者消费了大量的消息如果没有确认的话,会导致消费者连接节点的内存消耗变大,所以找到合适的预取值是一个反复试验的过程,不同的负载该值取值也不同 100 到 300 范围内的值通常可提供最佳的吞吐量,并且不会给消费者带来太大的风险。
  • 2.预取值为 1 是最保守的。当然这将使吞吐量变得很低,特别是消费者连接延迟很严重的情况下,特别是在消费者连接等待时间较长的环境中。对于大多数应用来说,稍微高一点的值将是最佳的。

2.4.编码实现预取值:

相关推荐
Thomas.Sir4 天前
第21课:PyTorch|GPU多卡训练与分布式训练基础【让多卡并行成为你的加速引擎】
人工智能·pytorch·分布式
Cicada1285 天前
库存消息消费的正确性设计——从幂等窗口到批量流水线
分布式·系统架构
Y3815326625 天前
Ruby 调用谷歌搜索 API:net/http 与 json 标准库实战
搜索引擎·ruby
Francek Chen5 天前
【大数据处理与分析】数据仓库Hive:04 数据仓库Hive概述
大数据·数据仓库·hive·hadoop·分布式
Gl�ria6 天前
Hadoop/YARN 集群缩容:下线DN节点
大数据·hadoop·分布式
吉甫作诵6 天前
Kafka 集群安装与运维实战:消费组排查、Offset 重置与副本重分配
大数据·运维·分布式·kafka·消息队列
imDwAaY6 天前
消息队列四大核心问题:顺序性、幂等性、可靠性与一致性
学习·kafka·rabbitmq
是Dream呀6 天前
Harness 工程:让 Agent 真正把任务做完
人工智能·分布式·缓存·agent
yt004yt6 天前
绿岛数字化平台搭建:VOCs 监测与能碳数据一体化方案
大数据·分布式