[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.编码实现预取值:

相关推荐
..空空的人13 小时前
C++基于protobuf实现仿RabbitMQ消息队列---项目设计
分布式·rabbitmq
毕设源码-赖学姐13 小时前
【开题答辩全过程】以 基于Spark的电商用户行为分析系统为例,包含答辩的问题和答案
大数据·分布式·spark
我认不到你13 小时前
paxos一致性算法(大白话+图解)
分布式·后端
川2113 小时前
Kafka消息中间件(超大数据吞吐量)使用
分布式·kafka
Wang's Blog14 小时前
Kafka: 基于 NestJS 的问卷系统配置与业务实现
分布式·kafka
回家路上绕了弯14 小时前
一文读懂分布式事务:核心原理、解决方案与实践思考
分布式·后端
踏浪无痕14 小时前
JobFlow 背后:五个让我豁然开朗的设计瞬间
分布式·后端·架构
我是小妖怪,潇洒又自在14 小时前
springcloud alibaba(十)分布式事务
分布式·spring cloud·wpf
Q87622396514 小时前
基于S7 - 200 PLC和组态王的大小球颜色大小材质分拣系统探索
分布式
小满、16 小时前
RabbitMQ:Fanout、Direct、Topic 交换机、队列声明与消息转换器
java·分布式·消息队列·rabbitmq·spring amqp