MQ问题集（kafka主从同步与高可用，MQ重复消费、幂等）

最新推荐文章于 2025-07-21 09:41:31 发布
最新推荐文章于 2025-07-21 09:41:31 发布
阅读量805 收藏 1
点赞数
CC 4.0 BY-SA版权
分类专栏： 学习笔记 文章标签： kafka 主从同步 高可用 重复消费 幂等
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/zhaohong_bo/article/details/90634997
本文介绍了Kafka的主从同步和高可用性，并详细探讨了MQ重复消费的问题及其避免方法，包括MQ内部的幂等性实现以及消息消费者如何确保幂等性。内容涵盖消息发送流程、消息重复发送的原因与后果，以及幂等性设计策略。

1、kafka主从同步与高可用

https://1028826685.iteye.com/blog/2354570
http://developer.51cto.com/art/201808/581538.htm

2、MQ有可能发生重复消费，如何避免，如何做到幂等

2.1 MQ消息发送

在这里插入图片描述
1、发送端MQ-client(消息生产者：Producer)将消息发送给MQ-server；

2、MQ-server将消息落地；

3、MQ-server回ACK给MQ-client（Producer）；

4、MQ-server将消息发送给消息接受端MQ-client(消息消费者：Customer)；

5、MQ-client（Customer）消费接受到消息后发送ACK给MQ-server；

6、MQ-server将落地消息删除

2.2 消息重复发送原因

为了保证消息必达，MQ使用了消息超时、重传、确认机制。使得消息可能被重复发送，如上图中，由于网络不可达原因：3和5中断，可能导致消息重发。消息生产者a收不到MQ-server的ACK，重复向MQ-server发送消息。MQ-server收不到消息消费者c的ACK，重复向消息消费者c发消息。

2.3 消息重复发送产生的后果

最低0.47元/天 解锁文章

200万优质内容无限畅学
MQ - 41 容灾：跨地域、跨可用区的容灾和同步的方案设计
小工匠
10-11 9643
对于我们业务侧来说，我们需要保证业务在任何情况都能正常运行，即服务自身拥有容灾能力是基本要求。而消息队列作为基础组件，容灾是它的基本能力。我们将会详细讲一下消息队列集群在发生异常时如何做好容灾，以及异常时如何保证数据不丢失容灾是指当系统发生这些异常时，服务能够自动切换，并正常运行。我们是通过 RTO 和 RPO 来衡量容灾的质量。RTO 是指发生故障时业务系统所能容忍的最长停止服务时间，RPO 是指在故障期间能够容忍多少数据丢失。业务追求的是 RTO 和 RPO 都为 0，或者无限趋近于 0。
面试：消息中间件RabbitMQ和Kafka(保证消息不丢失、重复消费、死信交换机、延迟队列、消息堆积、高可用机制、消费的顺序性、数据清理机制、高性能设计)
icbbm的博客
05-03 1850
我们可以利用Spring的retry机制，在消费者出现异常时利用本地重试，设置重试次数，当次数达到了以后，如果消息依然失败，将消息投递到异常交换机，交由人工处理。一个topic的数据可能存储在不同的分区中，每个分区都有一个按照顺序的存储的偏移量，如果消费者关联了多个分区不能保证顺序性。RabbitMQ支持消费者确认机制，即:消费者处理消息后可以向MQ发送ack回执，MQ收到ack回执后才会删除该消息。抛出异常则返回nack；属性，指定了一个交换机，那么队列中的死信就会投递到这个交换机中，而这个交换机称为。
漫游Kafka设计篇之主从同步
红磊的专栏
07-09 2万+
Kafka允许tipci的分区拥有若干副本，这个数量是可以配置的，你可以为每个topci配置一个副本数量。Kafka会自动的在个副本上备份数据，所以当一个server down掉时数据依然是可用的。 Kafka的副本功能不是必须的，你可以配置只有一个副本，这样其实就相当于只有一份数据。 创建副本的单位是topic的分区，每个分区都有一个leader和零或多个followers.所有的读写操作都
MQ 有可能发生重复消费，如何避免，如何做到幂等
NZC2237的博客
12-21 1697
在实际应用中，通常结合以上方法，根据具体业务和系统特点选择合适的方案。重要的是要在消息消费端和系统设计中考虑这些机制，以确保系统在面对消息重复消费时能够保持一致性和稳定性。
RabbitMQ消息重复消费？这篇给你整明白！
最新发布
weixin_42148384的博客
07-21 1620
Rabbit MQ有个核心特性——“至少一次投递”（At-Least-Once）：为了保证消息绝对不丢失，Broker会想尽办法把消息送到消费者手里；但如果消费者没明确告知“我处理完了”，Broker就会认为消息“可能没送达”，过段时间再重新投递。这就导致了消费者可能多次收到同一条消息，也就是我们常说的“重复消费”。本文将从​​重复消费的底层原因​​出发，结合实际开发中的踩坑经验，详细拆解4类主流解决方案，助你告别重复消费的困扰！
消息队列MQ详解（kafka）
wang_nian的博客
08-17 1717
解决的问题： 解耦 异步 削峰 不用 MQ 系统耦合场景 A 系统产生了一个比较关键的数据，很多系统需要 A 系统将数据发过来，强耦合（B,C,D,E 系统可能参数不一样、一会需要一会不需要数据，A 系统要不断修改代码维护） A 系统还要考虑 B、C、D、E 系统是否挂了，是否访问超时？是否重试？ 使用 MQ 系统解耦场景 维护这个代码，不需要考虑人家是否调用成功，失败超时 如果新系统需要数据，直接从 MQ 里消费即可，如果某个系统不需要这条数据就取消对 MQ 消息的消费即可。...
查看kafka的主从状态_Kafka 集群部署
weixin_30272849的博客
02-01 4283
ip地址 主机名 安装软件192.168.20.40 k8s-master zookeeper、kafka192.168.20.43 k8s-node2 zookeeper、kafka192.168.20.39 k8s-node3 zookeeper、kafka三个节点安装zoo...
Kafka 3.0 源码笔记(9)-Kafka 服务端元数据的主从同步
谈谈1974
04-04 3743
文章目录前言1. 元数据主从同步的流程1.1 两次 Fetch 完成 HW 同步1.2 一次 Fetch 完成 HW 同步2. 元数据主从同步源码分析2.1 Follower 节点 Fetch 请求的发起2.2 Leader 节点对 Fetch 请求的处理2.3 Follower 节点对 Fetch 响应的处理 前言 在 Kafka 3.0 源码笔记(8)-Kafka 服务端对创建 Topic 请求的处理 中笔者分析介绍了 Kafka 集群的 Leader 节点更新保存元数据的流程，而元数据保存下来后必然要
大厂消息中间件高频面试题与知识点整理（RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、MetaMQ）
热门推荐
张彦峰的博客
04-07 172万+
互联网高频面试之消息中间件基本问题和知识点整理分析
MQ之kafka
swimming_in_IT_的博客
03-27 1381
Kafka是最初由Linkedin公司开发，是一个分布式、支持分区的（partition）、多副本的（replica），基于zookeeper协调的分布式消息系统，它的最大的特性就是可以实时的处理大量数据以满足各种需求场景：比如基于hadoop的批处理系统、低延迟的实时系统、storm/Spark流式处理引擎，web/nginx日志、访问日志，消息服务等等，用scala语言编写，Linkedin于2010年贡献给了Apache基金会并成为顶级开源 项目。
kafka 主从同步入门
鸭梨的博客
02-05 2765
概念 就是follwer同步leader的信息 过程 怎么同步? 1 生产者写入消息,leader更新LEO 2 leader通知follwer来取消息,follwer开始fetch数据 3 follwer同步的速度是不一样的,有的快,有的慢,以所以follwer最小的offset为准,leader会更新HW值 4 所有的follwer都跟上了leader,leader会再次更新HW 5 leader负责读写,follwer阻塞以等待新的消息 follwer跟不上节奏怎么办? 如果follower“落后
kafka高可用设计
02-14
kafka高可用方案(双活，单活等)调研和设计，列出高可用设计需要考虑的点
MQ消息队列的重复消费问题的通用解决办法以及幂等性的原理
终生学习践行者
10-23 7731
详细介绍了MQ消息队列重复消费的原因，以及通过保证幂等性来避免重复消费带来的问题。
消息中间件(二)——RabbitMQ和Kafka的高可用
zengdongwen的博客
09-05 577
上一讲我们说到了使用MQ的好处，同时也对比了各种消息中间件的区别及其优势。这一次我们就来说说消息队列的高可用的原理。这里主要讲的是现在使用比较多的RabbitMQ和大数据相关的Kafka两种消息中间件的高可用。这里只是讲解他们的实现原理，不会实战。 1、RabbitMQ的高可用 RabbitMQ是基于主从复制来实现高可用的，不支持分布式。既然是主从复制，那么肯定就不是单台机器能保...
Kafka：kafka的主从模式和故障切换 ②
有才而性缓，定属大才。有智而气和，斯为大智。
02-24 1774
因此，如果分区数量固定，消费者数量的上限就是分区的数量。这种方式更类似于Leader-Follower模式，而不是传统意义上的主从模式，因为在Kafka中，每个Broker（Kafka的服务器节点）都可能成为某个Partition的Leader，也可能是Follower，这取决于你如何配置和使用你的Kafka集群。需要注意的是，一个Partition在一个消费者组中，一次只能被一个消费者消费，所以消费者组中的消费者数量不能超过总的Partition数量，否则多余的消费者将会闲置。
面试官：MQ 消息丢失、重复、积压问题，如何解决？一文带你了解
程序源日志的博客
01-28 312
至此，我们讲解了 MQ 消息队列的热门问题的解决方案，无论是初中级还是高级研发工程师，本篇文章的内容都是你需要掌握的，你都可以从这几点出发，与面试官进行友好的交流。我来总结一下今天的重点内容。如何确保消息不会丢失？你要知道一条消息从发送到消费的每个阶段，是否存在丢消息，以及如何监控消息是否丢失，最后才是如何解决问题，方案可以基于“ MQ 的可靠消息投递 ”的方式。如何保证消息不被重复消费？在进行消息补偿的时候，一定会存在重复消息的情况，那么如何实现消费端的幂等性就这道题的考点。如何处理消息积压问题？
kafka消息发送者
之城的专栏
07-26 652
kafka不仅仅可以作为MQ消息系统来使用，也可以作为存储系统和流式处理平台使用。kafka使用磁盘顺序写入的基本机制来实现海量消息的处理和消息的有序性，同时也保证了消息不会丢失。kafka也是分布式的系统，使用zookeeper（2.8已经移除）来协调各个部分。分布式系统可以显著的提高系统的可用性，但是同时也为系统引入了数据一致性的挑战。为了达到高度的数据一致性，kafka又引入了副本备份的概念，保证在分布系统中某个模块出现问题而不会导致数据丢失。broker服务器。...
说说 MQ 之 Kafka(超详细)
cowbin2012的专栏
05-04 1万+
原文：http://valleylord.github.io/post/201607-mq-kafka/ 现代的互联网分布式系统，只要稍微大一些，就一定逃不开3类中间件：远程调用（RPC）框架、消息队列、数据库访问中间件。Kafka 是消息队列中间件的代表产品，用 Scala 语言实现，本文采用的是 Kafka_2.11 0.10.0.0 版本进行实验。 基本概念 首先，Kafka 中有一些基...
MQ如何防止消息被重复消费？
qq_45228323的博客
03-03 4076
被询问如何防止MQ消息被重复消费时，其实是在考察候选人对消息队列、分布式系统设计以及容错机制的理解，通过这些问题，可以全面了解候选人在处理MQ消息重复消费问题时的思考方式、技术能力和实践经验，从而评估其是否适合担任相关岗位。
RabbitMQ、RocketMQ与Kafka：三大MQ框架的实战比较与面试攻略
2. 高性能：采用主从架构，易于水平扩展，注重生产与消费性能。 3. 可靠性：支持严格的顺序投递、事务消息和定时/延时功能，满足金融级别的需求。 4. 批处理：提高系统效率，通过批量操作减少网络开销。 5. 云原生：...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值