后端工程师的高阶面经
邓明
前 Shopee 高级工程师,Beego PMC
6888 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 50 讲
后端工程师的高阶面经
15
15
1.0x
00:00/00:00
登录|注册

26|消息不丢失:生产者收到写入成功响应后消息一定不会丢失吗?

你好,我是大明。今天我们来学习消息队列中的新主题——消息丢失。
和消息丢失相对应的概念叫做可靠消息,这两者基本上指的就是同一件事。在实践中,一旦遇到消息丢失的问题,是很难定位的。从理论上来说,要想理解消息丢失,就需要对生产者到消费者整个环节都有深刻地理解。
今天我就带你看看从生产者发出,到消费者完成消费,每一个环节都需要考虑什么才可以确保自己的消息不会丢失。到最后,我会再给你一个在 Kafka 的基础上支持消息回查的方案,帮助你在面试的时候赢得竞争优势。让我们先从基础知识开始。

Kafka 主从同步与 ISR

在 Kafka 中,消息被存储在分区中。为了避免分区所在的消息服务器宕机,分区本身也是一个主从结构。换一句话来说,不同的分区之间是一个对等的结构,而每一个分区其实是由一个主分区和若干个从分区组成的。
不管是主分区还是从分区,都放在 broker 上。但是在放某个 topic 分区的时候,尽量做到一个 broker 上只放一个主分区,但是可以放别的主分区的从分区。
这种思路也很容易理解,它有点像是隔离,也就是通过将主分区分布在不同的 broker 上,避免 broker 本身崩溃影响多个主分区。

写入语义

结合我们在 MySQL 部分对写入语义的讨论,你就可以想到,当我们说写入消息的时候,既可以是写入主分区,也可以是写入了主分区之后再写入一部分从分区。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文深入探讨了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归属地:北京
收起评论
显示
设置
留言
7
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部