26|消息不丢失:生产者收到写入成功响应后消息一定不会丢失吗?
Kafka 主从同步与 ISR
写入语义
- 深入了解
- 翻译
- 解释
- 总结
本文深入探讨了Kafka消息队列中的消息丢失问题,从主从同步与ISR、写入语义、消息丢失的各种场景等方面展开讨论。即使在ack=all的情况下,仍存在主从同步、刷盘、消费者提交等环节可能导致消息丢失的情况。文章介绍了Kafka中的一些核心概念和参数,如ISR、unclean选举、log.flush.interval.messages等,以及它们对消息丢失的影响。通过对这些关键环节的分析,读者可以更全面地了解消息丢失的可能场景和原因,从而更好地保障消息的可靠性。 文章还介绍了在Kafka上支持消息回查机制的亮点方案,以及回查实现、数据存储和有序消息等方面的设计细节。这些方案和实现能够体现作者的设计能力和解决业务问题的能力。同时,文章提出了思考题,引发读者对于支持Kafka回查机制中可能出现的问题和优化方向的思考。 总的来说,本文内容丰富,深入浅出,适合技术人员深入学习和理解消息队列中的消息丢失问题,尤其对于使用Kafka的开发人员具有一定的参考价值。
《后端工程师的高阶面经》,新⼈⾸单¥59
全部留言(7)
- 最新
- 精选
- 进击的和和作者你好 结尾今日课程总结的图好考验视力呀
编辑回复: 同学你好,26、27课的图片已经替换,现在是清晰版本,感谢反馈🌹
2023-08-16归属地:四川6 - sheep问一个小问题,课后问题中,“要是回查中间件把消息转发到业务 topic 了,但是标记成已发送失败”,这样子的情况下会产生重复的消息,消费者要做好幂等性。但是什么情况下会出现已经发送过去了,但被标记为已发送失败这种情况呢,一般是网络问题?
作者回复: 数据库崩了。你刚发出去,然后数据库崩了,或者网络抖动。又或者你刚发出去,结果应用自己崩了。
2023-12-28归属地:广东1 - Geek8004尝试回答下上面的题目: 1.在支持 Kafka 回查机制中,要是回查中间件把消息转发到业务 topic 了,但是标记成已发送失败,会发生什么? 答:会产生重复的消息 在支持 Kafka 回查机制中,你可以考虑把关系型数据库换成 Redis,这样换的话有什么优缺点? 答:优点:性能高,毕竟redis比mysql耐打;缺点:1.扫key的时候容易阻塞redis?2.掉电之后如果持久化机制如果不是每条数据都落盘的话,掉电之后可能造成消息丢失? 请老师帮忙check下
作者回复: 赞!第一个问题,在落地的时候,要注意异步检查这种异常情况。 第二个问题也对,正常如果 Redis 用了 Cluster,可用性很高的话,直接用 Redis 就可以。
2023-08-31归属地:中国香港1 - Qualifor本地事务表加补偿机制这种方式真的有必要吗,感觉如果那么麻烦来保证持久性,kafka的优势完全没有了呀,直接用mysql得了呗
作者回复: 使用 kafka 的核心是为了解耦、削峰和限流。从这个角度来说,因为本息消息表的性能限制,所以削峰和限流基本没啥效果,也就是说,mysql 该崩还是崩。因此这种形态下,只能说是为了解耦了。直接使用 mysql 的话,其实你就是将 mysql 当成了消息队列,那么这个时候你就要自己手动解决消费者组、偏移量之类的问题了。
2023-12-30归属地:河北 - 浩仔是程序员老师你好,这个消息回查是为了解决什么问题,如果是为了解决生产者发送成功,那本地消息表也可以,感觉消息回查增加了复杂度。我一开始以为的消息回查是业务方生产者写kafka,消费者消费完会回写一个结果给生产者,但是如果生产者一直没有收到消费者的回写,那生产者就会回查消费者提供的接口,更换对应的状态
作者回复: 这个纯纯就是面试用的,我个人也不怎么喜欢用回查。之前某些 MQ 提供消息回查的时候我还吐槽过这就是中间件研发者闲着没事给自己刷 KPI。 你说的那种,是业务比对。就是要保证生产者的消息一定被消费了。但是也不是好的实践,因为生产者理论上来说,是不应该知道有消费者,有哪些消费者的,毕竟你们都通过 QM 解耦了。
2023-09-02归属地:广东3 - Feng最近遇到个kafka消费者重新订阅某个主题,但是生产者的消息来的太快导致没有消费到的问题; python client可以consumer循环poll直到partition_EOF再通知生产消息,但是Java好像没有这个机制。
作者回复: 我没懂,你的意思是不是你还没订阅,生产者就生产消息了?这种情况不是指定偏移量就可以吗?或者说从 Oldest 开始消费。还是你这里有啥特殊的问题?
2023-08-18归属地:广东 - peter请教老师两个问题: Q1:一个broker需要部署在一台机器上吗? Q2:回看中间件,相当于基于MQ进行二次开发了,需要针对选择的MQ,不具有通用性,是吗?
作者回复: 1. 你可以认为,一个 broker 就是一个进程,一般是建议独立部署的 2. 不不不,你的数据库存储部分,和回查部分是,是通用的。只有真的和 Kafka 打交道的部分,才用不上。
2023-08-16归属地:北京