首页
学习
活动
专区
圈层
工具
发布

『假如我是面试官』RabbitMQ我会这样问!

因此RabbitMQ出现消息丢失的情况有四个 分别是 消息生产者没有成功将消息发送到MQ导致消息丢失 交换机未路由到消息队列导致消息丢失 消息在MQ中时,MQ发生宕机导致消息丢失 消费者消费消息时出现异常导致消息丢失...除了事务之外,RabbitMQ还提供了生产者确认机制(publisher confirm)。...如何保证消息不重复消费(如何保证消息的幂等性) 消息重复的原因有两个: 生产时消息重复 由于生产者发送消息给MQ,在MQ确认的时候出现了网络波动,生产者没有收到确认,实际上MQ已经接收到了消息。...这时候消费者就接收到了两条一样的消息。 由于消息重复是网络波动等原因造成的,无法避免,我们能做的的就是保证消息的幂等性,以防业务重复处理。...消息大量堆积应该怎么处理 消息堆积的原因有两个 网络故障,消费者无法正常消费 消费方消费后未进行ack确认 解决方案如下: 检查并修复消费者故障,使其正常消费 编写临时程序将堆积的消息发送到容量更大的MQ

63330

线上Kafka突发rebalance异常,如何快速解决?

消费组指的是多个消费者(consumer)组成起来的一个组,它们共同消费 topic 的所有消息,并且一个 topic 的一个 partition 只能被一个 consumer 消费。...因此,如果你的消费者组停掉了很长时间(超过 7 天),那么 Kafka 很可能就把该组的位移数据删除了。...协调者收到 LeaveGroup 请求后,依然会以心跳响应的方式通知其他成员,因此我就不再赘述了,还是直接用一张图来说明。 ? 组成员崩溃 崩溃离组是指消费者实例出现严重故障,突然宕机导致的离组。...而 kafka 的消费者参数设置中,跟消费处理的两个参数为: max.poll.interval.ms 每次消费的处理时间 max.poll.records 每次消费的消息数 对于这种情况,一般来说就是增加消费者处理的时间...除此之外,超时时间参数(session.timeout.ms)与 消费者每次处理的时间(max.poll.interval.ms)也是有关联的。

7.3K22
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    【消息队列】基于RabbitMQ实现延迟队列

    那么,RabbitMQ延迟队列是什么? “RabbitMQ延迟队列允许生产者发送消息时指定一个延迟时间,消费者不会立即收到消息,而是在指定的延迟时间之后才收到消息。...设置一定的延迟时间,将订单信息逐步发送到RabbitMQ中,以平滑处理流量高峰。 消息重试:当消息消费失败时,为了避免立即重试可能导致的重复消费和系统负载增加,可以将失败的消息放入延迟队列中。...: “原本指定交换机类型的地方使用了x-delayed-message这个值,那么这个交换机除了支持延迟消息之外,到底是direct、fanout、topic这些类型中的哪一个呢?...,也会导致returnedMessage()方法执行 ③消费者端效果 5....这里选择了第二种方案,即安装rabbitmq-delayed-message-exchange插件,该插件允许生产者发送消息时指定延迟时间,消费者将在指定的延迟时间后收到消息。

    97910

    【MQ04】消息持久化与确认机制

    对于这两个功能,大部分消息队列应用都会通过持久化机制和消息确认机制来实现,我们今天先从 RabbitMQ 的相关功能说起。 持久化 为了效率,为了性能,消息队列产品基本都是内存型的一种数据库。..., false, false); 然后,在消息对象实例化的时候,通过增加一个 delivery_mode 参数,指定消息持久化。...这个测试大家自己测一下就好,等录视频的时候我再详细演示吧。 惰性队列 除了普通的持久化之外,RabbitMQ 还提供了一种叫做“惰性队列”的功能。...消息队列的 ACK ,其实就是说,在默认情况下,如果一条消息被取走了,就像 Redis 里被 POP 了,那么这条消息就直接从队列中删除了。 但是,试想一个问题,那就是消费者处理失败了,出现异常了。...发布确认 除了消息的确认之外,还有发布确认。上面的 ACK 确认,确认的是消息是否被消费完成。而发布确认,则是说消息是否被发布到了队列中。

    72710

    【云原生进阶之PaaS中间件】第四章RabbitMQ-4.3-如何保证消息的可靠性投递与消费

    但任何一项技术的引入,除了带来它自身的优点之外,必然也会带来其他的一些缺点。MQ消息中间件虽然可以做到系统之间的解耦以及异步通信,但可能会存在消息丢失的风险。...简单来说,就是producer发送了一条消息出去,但由于某种原因(比如RabbitMQ宕机了),导致consumer没有消费到这条消息,最终导致producer与consumer两个系统的数据与期望结果不一致...当RabbitMQ发生故障导致消息丢失,也会发送一个不确认(nack)的消息给producer,nack消息中也会包含producer发布的消息唯一ID,producer接收到nack的消息之后,可以针对发布失败的消息做相应处理...中定义了两个方法,一个是handleAck,用来处理RabbitMQ的ack确认消息,一个是handleNack,用来处理RabbitMQ的nack未确认消息,这两个方法会在RabbitMQ完成消息确认和发生故障导致消息丢失时回调...重发->退回...... (2)备胎Exchange交换机 除了使用ReturnListener,我们还可以使用备胎交换机的方式来解决Routing key不存在导致消息不可达的问题。

    45810

    18道kafka高频面试题哪些你还不会?(含答案和思维导图)

    8、数据传输的事务定义有哪三种? 9、Kafka 判断一个节点是否还活着有那两个条件?...,每个消息都传输被一次而且仅仅被传输一次,这是大家所期望的 9、Kafka 判断一个节点是否还活着有那两个条件?...1:服务端会等待 ack 值 leader 副本确认接收到消息后发送 ack 但是如果 leader挂掉后他不确保是否复制完成新 leader 也会导致数据丢失。...消费者提供两个配置设置来控制 poll 循环: max.poll.interval.ms:增大 poll 的间隔,可以为消费者提供更多的时间去处理返回的消息(调用 poll(long)返回的消息,通常返回的消息都是一批...还要注意,你需要 pause 暂停分区,不会从 poll 接收到新消息,让线程处理完之前返回的消息(如果你的处理能力比拉取消息的慢,那创建新线程将导致你机器内存溢出)。 ?

    1.2K20

    上线之后,消息收不到了!

    可以看到消费端尝试连接一个 20878 的端口,但是由于网络问题,一直连接失败。 那这个 20878 是什么端口?...假设当前 rocketmq broker 端存在一个 topic ,拥有四个队列,关系如下: ? 此时如果有一个消费者使用集群模式消费消息,那么它将需要负责消费所有队列中的消息。 ?...当我们再增加一个消费者消费消息时,此时消费端将会自动进行重平衡,默认情况下将会使用平均分配原则。 ? 可以看到 Rebalance 机制可以提升的消息的并行处理机制。...为什么 mq 控制台重新发送的消息消费者可以收到? rocketmq 控制台重新发送消息代码如下: ?...那为什么开启两个监听端口那?我想很多同学应该也有这个疑惑,这里给出一个开发者解释答案。 https://github.com/apache/rocketmq/issues/1510 ?

    1.3K21

    redis实现消息队列

    Redis 是否存在这样一种机制:如果队列为空,消费者在拉取消息时就「阻塞等待」,一旦有新消息过来,就通知我的消费者立即处理新消息呢?...之后,再启动一个生产者,发布一条消息。 127.0.0.1:6379> PUBLISH queue msg1 (integer) 1 这时,2 个消费者就会解除阻塞,收到生产者发来的新消息。...这种设计方案,就导致了上面提到的那些问题。 例如,如果一个消费者异常挂掉了,它再重新上线后,只能接收新的消息,在下线期间生产者发布的消息,因为找不到消费者,都会被丢弃掉。...,数据也会丢失 有没有发现,除了第一个是优点之外,剩下的都是缺点。...这里不再重点介绍 Stream 命令的各种参数,我在例子中演示时,凡是大写的单词都是「固定」参数,凡是小写的单词,都是可以自己定义的,例如队列名、消息长度等等,下面的例子规则也是一样,为了方便你理解,这里有必要提醒一下

    1.1K20

    你能说出 Kafka 这些原理吗

    控制器的作用 那么说了这么多,控制是什么呢?控制器的作用是什么呢?或者说控制器的这么一个组件被设计用来干什么?别着急,接下来我们就要说一说。...如上图所示,为了简单我只画出了两个 broker ,每个 broker 指保存了一个 Topic 的消息,在 broker1 中分区0 是Leader,它负责进行分区的复制工作,把 broker1 中的分区...关于副本机制我们说了这么多,那么副本机制的好处是什么呢? 能够立刻看到写入的消息,就是你使用生产者 API 成功向分区写入消息后,马上使用消费者就能读取刚才写入的消息 能够实现消息的幂等性,啥意思呢?...在了解重平衡之前,你需要知道这两个角色 群组协调器(Coordinator):群组协调器是一个能够从消费者群组中收到所有消费者发送心跳消息的 broker。...重平衡过程可以从两个方面去看:消费者端和协调者端,首先我们先看一下消费者端 从消费者看重平衡 从消费者看重平衡有两个步骤:分别是 消费者加入组 和 等待领导者分配方案。

    69510

    06 Confluent_Kafka权威指南 第六章:数据传输的可靠性

    这种leader选举是干净的,因为它保证了提交数据不会丢失。根据定义,提交的数据存在于所有同步副本上。 但是,我们除了当前的故障副本之外没有同步的副本可用怎么办?...需要注意的是重试将会导致一个风险,就是两个消息都写入到broker从而导致数据重复。...这保证kafka消费者将总是正确的顺序获得新数据,而不会遗漏任何消息。 当一个消费者停止工作的时候,另外一个消费者知道要从哪开始工作,前一个消费者的停止之前处理的最后一个offset是什么?...: 第一个参数是group.id,正如在第四章中详细解释的那样,基本的思路是,两个消费者如果有相同的group id 和订阅一个相同的topic,每个消费者将非配topic的一个子集。...如果你选择latest,消费者将从分区的末尾开始,这将尽量减少消费者重复处理消息,但是几乎肯定的导致消费者错过很多消息。 第三个相关的参数是enable.auto.commit。

    2.3K20

    ActiveMQ --- 入门篇

    结论:消息不能被重复消费。 -- 先启动两个消费者,再启动生产者生产消息: ------- 结果就是两个消费者一人消费一半。...点对点传输还有如下特点: 每条消息只能有一个消费者,也就是上面说的消息不能被重复消费; 消息生产者和消费者没有时间上的关联,生产消息时不用管是不是有人消费,消费者也随时可以提取消息; 消息被消费后将不会再存储...消息属性 是什么:一个对象的属性能干嘛?...然后再运行生产者发送信息,此时,不论消费者是否还在线,都会接收到消息,不在线的话,下次连接的时候,会把没有收过的消息都接收下来。...---- 事务:创建session的时候要传两个参数,一个是事务,一个是签收。

    4.6K20

    Java开发面试--RabbitMQ专区1

    流量削峰:在高流量的系统中,可以通过RabbitMQ来缓存高峰期的消息,然后在合适的时候处理这些消息,从而防止因处理高流量导致的系统崩溃。...路由消息到队列:交换器接收到消息后,将根据消息的路由键和它自身类型(direct、topic、fanout或headers等)以及当前的绑定规则,决定将消息路由到哪一个或哪些队列上。...处理完成之后,消费者需要向RabbitMQ发送一个确认信号,告诉RabbitMQ这个消息已经被正确处理,RabbitMQ收到确认信号后,会从队列中移除这条消息。...生产者在发布消息到交换器时,可以指定该消息需要RabbitMQ的确认。RabbitMQ收到消息后,会返回一个确认消息给生产者。如果生产者没有收到确认消息,那么就有可能需要重新发送该消息。...消费者从队列中获取消息后,完成消息处理,然后需要向RabbitMQ发送一个确认消息,告诉RabbitMQ这个消息已经被处理,可以从队列中删除了。这种机制保证了每个消息都被成功处理。

    30510

    18道kafka高频面试题哪些你还不会?(含答案和思维导图)

    8、数据传输的事务定义有哪三种? 9、Kafka 判断一个节点是否还活着有那两个条件?...,每个消息都传输被一次而且仅仅被传输一次,这是大家所期望的 9、Kafka 判断一个节点是否还活着有那两个条件?...1:服务端会等待 ack 值 leader 副本确认接收到消息后发送 ack 但是如果 leader挂掉后他不确保是否复制完成新 leader 也会导致数据丢失。...消费者提供两个配置设置来控制 poll 循环: max.poll.interval.ms:增大 poll 的间隔,可以为消费者提供更多的时间去处理返回的消息(调用 poll(long)返回的消息,通常返回的消息都是一批...还要注意,你需要 pause 暂停分区,不会从 poll 接收到新消息,让线程处理完之前返回的消息(如果你的处理能力比拉取消息的慢,那创建新线程将导致你机器内存溢出)。

    1.3K00

    《我想进大厂》之kafka夺命连环11问

    对于传统的消息队列系统支持两个模型: 点对点:也就是消息只能被一个消费者消费,消费完后消息删除 发布订阅:相当于广播模式,消息可以被所有消费者消费 上面也说到过,kafka其实就是通过Consumer...acks=all,这个参数有可以配置0|1|all。 0表示生产者写入消息不管服务器的响应,可能消息还在网络缓冲区,服务器根本没有收到消息,当然会丢失消息。...1表示至少有一个副本收到消息才认为成功,一个副本那肯定就是集群的Leader副本了,但是如果刚好Leader副本所在的节点挂了,Follower没有同步这条消息,消息仍然丢失了。...我认为可以从两个个方面来回答这个问题: 首先,从运维的复杂度来看,Kafka本身是一个分布式系统,他的运维就已经很复杂了,那除此之外,还需要重度依赖另外一个ZK,这对成本和复杂度来说都是一个很大的工作量...OK,最后一个大家都问的问题,Kafka为什么快? 嘿,这个我费,我背过好多次了!

    67530

    深入浅出 RabbitMQ-RabbitMQ消息确认机制(ACK)

    大家好,我是工藤学编程 一个正在努力学习的小博主,期待你的关注 实战代码系列最新文章 C++实现图书管理系统(Qt C++ GUI界面版) SpringBoot实战系列 【SpringBoot实战系列...消费者从RabbitMQ的Broker(消息代理)中监听消息时,存在两个关键风险: 消费者接收到消息后,还没处理完就因“网络波动”“服务器宕机”挂了; 消息处理过程中抛出异常(比如数据库连接失败),导致业务逻辑没执行完...而ACK机制的核心逻辑是:消费者处理完消息后,主动给RabbitMQ发一个“确认信号(ACK)”,RabbitMQ只有收到这个信号,才会真正删除消息。 二、ACK机制的核心原理 1....如果消息被消费者接收后未发送ACK,它会处于“Unacked”状态——这个状态下,RabbitMQ不会把消息重新投递给其他消费者,也不会删除,直到: 收到消费者的ACK/NACK(拒绝)信号; 消费者进程退出...它的核心作用是:消费者确认/拒绝消息时,必须通过DeliveryTag告诉RabbitMQ“我要操作哪条消息”,避免“认错消息”。

    55210

    RabbitMQ的工作队列

    1、轮训分发消息 工作线程接收消息,采用轮询接收,三个线程中只有一个能接收到 案例:启动两个线程,一个线程发送消息,看看他们是如何工作的?...启动消费者,然后勾选all ... instance,允许多个实例 4、测试结果 通过程序执行发现生产者总共发送 4 个消息,消费者 1 和消费者 2 分别分得两个消息,并且是按照有序的一个接收一次消息...为了保证消息在发送过程中不丢失,rabbitmq 引入消息应答机制,消息应答就是:消费者在接收到消息并且处理该消息之后,告诉 rabbitmq 它已经处理了,rabbitmq可以把该消息删除了。...4、不公平分发 在最开始的时候我们学习到 RabbitMQ 分发消息采用的轮训分发,但是在某种场景下这种策略并不是很好,比方说有两个消费者在处理任务,其中有个消费者 1 处理任务的速度非常快,而另外一个消费者...,会导致消费者连接节点的内存消耗变大,所以找到合适的预取值是一个反复试验的过程,不同的负载该值取值也不同 100 到 300 范围内的值通常可提供最佳的吞吐量,并且不会给消费者带来太大的风险。

    56530

    Redis Streams介绍

    除了XREAD可以同时访问多个流,以及我们能够指定我们拥有的最后一个ID以获取更新的消息之外,在这个简单的形式中,没有做与XRANGE不同的一些事情。...但是,有趣的部分是我们可以通过指定BLOCK参数轻松地在阻塞命令中使用XREAD: > XREAD BLOCK 0 STREAMS mystream $ 注意,在上面的示例中,除了删除COUN选项之外,...正如您上面的命令中看到的,在创建消费者组时,我们必须指定一个ID,在示例中是$。这是必需的,因为消费者组在其他状态中必须知道在连接后处理哪些消息,即刚刚创建该组时的最后消息ID是什么?...XREADGROUP非常类似于XREAD,也提供相同的BLOCK选项,否则它是一个同步指令。但是,必须始终指定一个强制选项GROUP,它拥有两个参数:消费者组的名称以及尝试读取的消费者的名称。...在最简单的形式中,只使用两个参数调用该命令,这两个参数是Stream的名称和消费者者组的名称。

    2.4K50

    你能说出 Kafka 这些原理吗

    控制器的作用 那么说了这么多,控制是什么呢?控制器的作用是什么呢?或者说控制器的这么一个组件被设计用来干什么?别着急,接下来我们就要说一说。...如上图所示,为了简单我只画出了两个 broker ,每个 broker 指保存了一个 Topic 的消息,在 broker1 中分区0 是Leader,它负责进行分区的复制工作,把 broker1 中的分区...关于副本机制我们说了这么多,那么副本机制的好处是什么呢? 能够立刻看到写入的消息,就是你使用生产者 API 成功向分区写入消息后,马上使用消费者就能读取刚才写入的消息 能够实现消息的幂等性,啥意思呢?...在了解重平衡之前,你需要知道这两个角色 群组协调器(Coordinator):群组协调器是一个能够从消费者群组中收到所有消费者发送心跳消息的 broker。...重平衡过程可以从两个方面去看:消费者端和协调者端,首先我们先看一下消费者端 从消费者看重平衡 从消费者看重平衡有两个步骤:分别是 消费者加入组 和 等待领导者分配方案。

    1.1K21

    Kafka中的再均衡

    在使用Kafka时,除了消费者数量可能会变化,分区数量也同样可能变化,我们可以人为的对分区数量进行修改,但是Kafka只允许增加分区,所以我们只能把分区数量调大,不能调小,否则会收到InvalidPartitionException...除了消费者、分区数量的变化,还有一种情况,也需要进行再均衡。...而消费者数量减少则除了是人为操作,也可能因为其他原因导致,属于计划之外的再均衡,这是我们需要关心的,毕竟再均衡的开销还是很大的,所有消费者都会停止工作,所以我们应尽量避免不必要的再均衡。...下面我们看下影响消费者数量减少的参数有哪些: session.timeout.ms:Broker端参数,消费者的存活时间,默认10秒,如果在这段时间内,协调者没收到任何心跳,则认为该消费者已崩溃离组;...流程 当消费者收到协调者的再均衡开始通知时,需要立即提交偏移量; 消费者在收到提交偏移量成功的响应后,再发送JoinGroup请求,重新申请加入组,请求中会含有订阅的主题信息; 当协调者收到第一个JoinGroup

    1.1K30
    领券